search

maxwellhadley / node-red-contrib-rfxcom

node-RED nodes to access an RFXtrx433 transceiver
BSD 2-Clause "Simplified" License
22 stars 13 forks source link

Problem with Etiger E5-RC1 remote #122

Open JohnRabbit1 opened 2 years ago

JohnRabbit1 commented 2 years ago

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

maxwellhadley commented 2 years ago

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 status.state value and decode it yourself: it's the value of the penultimate byte in the message:

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 :(

JohnRabbit1 commented 2 years ago

Hi Max, I had some time this morning to do some testing. And it's even more strange (at least to me) I have played with the RFXmngr. I disabled all protocols but X10 and Lighting4. That gave the result als shown before. Enabling only X10 results to nothing (nothing was decoded) Enabling only Lighting4 results in a PT2262-like result. That is my workaround for now. Disabling X10 protocol. Later on I will look into the RFXcom api to see what's going wrong there.

maxwellhadley commented 2 years ago

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 rfx-PT2262-in device table to generate suitable payloads for your flow. It sounds like you are on this already!

The confusing thing here is that the mismatched packet type is so plausible - usually it is something completely wild