-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problem with Etiger E5-RC1 remote #122
Comments
This is very strange! The device is obviously a remote control, and the packet subtype for an X10 security remote control should be 3. But in your file it's not, it's 0 which is the subtype for a door sensor. A door sensor should send only status codes 0x0, 0x1, 0x2 & 0x3, not 0x9, 0xD, 0xB, or 0x6 - which is why the node is not decoding them properly. Yet RfxMgr seems to decode these 'wrong' commands OK. Looking at the documentation, the subtype does not actually need to be used to correctly decode the received status. It is probable that RfxMgr is ignoring it. But in that case why have different subtypes? Unless they are needed by the transmitter? The subtype does affect the encoding of the address bytes when transmitting. As a quick work-around, you can use the
At the moment I am unable to make any modifications (even if I had the spare time!) as I had to ditch my development environment, and haven't got round to rebuilding it yet :( |
Hi Max, |
Ahh! It looks like this is a 'Code Clash'. I had assumed the remote was actually a fully X10 compatible (alarm) device, but it seems not. It looks like it uses the PT2262 or one of its clones, and the pulse timings just happen to almost - but not quite - match another device family, in this case an X10 door sensor. I have come across this problem before. The RFXtrx appears to search received signals' pulse timings in a fixed order of packet types, and it outputs the first match found. It looks like X10 is earlier in the order than lighting4, so that is what gets output if both are enabled, and IIRC X10 is enabled by default. If you don't have any other X10 devices, then you should disable X10 and set up an The confusing thing here is that the mismatched packet type is so plausible - usually it is something completely wild |
Hi,
I have a problem with this device. In Rfxmgr this remote is properly recognised:
codes1.txt
However the rfx-detector node gives as result:
{"topic":"X10_DOOR/0xAF40","status":{"rssi":9,"battery":0,"tampered":false,"state":9,"delayed":false},"payload":"Battery Low","_msgid":"63c0f09d89ef139d"}
As you can see the subtype is not properly recognised (X10_Door....) And as a result all the other keys don't work.
So what should I do to make it work?
John
The text was updated successfully, but these errors were encountered: