LightwaveRF implementation not working

kevinkga commented 1 year ago

I am experiencing very strange behaviour with the LightwaveRF lib. I say it's strange because the same code that I used a few years ago does not seem to work now.

I am running an RFXtrx433e and the following tests were done using the latest Pro1 firmware version 1047

Putting a LightwaveRF Dimmer (gen1) into pairing mode and sending a switchOn("{someId}/1") does nothing to the device. However, this works when using their hub

When initiating pairing via the LightwaveRF mobile app, I have captured the following:

{
"subtype": 0,
"id": "0x0696B1",
"unitCode": 1,
"commandNumber": 1,
"command": "On",
"seqnbr": 0,
"level": 0,
"rssi": 7
}
2023-02-12 03:09:50.788 [rfxcom] on /dev/ttyUSB0 - Received: 0A,14,00,01,06,96,B1,01,01,00,70
{
"subtype": 0,
"id": "0x0696B1",
"unitCode": 1,
"commandNumber": 1,
"command": "On",
"seqnbr": 1,
"level": 0,
"rssi": 7
}

However, when I issue lightwaverf.switchOn("0x0696B1/1");, nothing happens. I also tried the following, just in case, but in vain:


var rfxcom = require('rfxcom');

var rfxtrx = new rfxcom.RfxCom("/dev/ttyUSB0", {debug: true}), lightwaverf = new rfxcom.Lighting5(rfxtrx, rfxcom.lighting5.LIGHTWAVERF);

//rfxtrx.on("receive", function (evt) { // console.log("Receive", JSON.stringify(evt,null,2)); //}) rfxtrx.on("lighting5", function (evt) { console.log(JSON.stringify(evt,null,2)); })

rfxtrx.initialise(function () { console.log("Device initialised"); lightwaverf.switchOn("0x0696B1/1"); lightwaverf.switchOn("0x0696B1/1",{mood: 0x03}); lightwaverf.switchOn("0x0696B1/1",{level: 0x10}); });


And here's the output for the above code:

~/rfxcom$ sudo node index.js 2023-02-12 03:25:04.006 [rfxcom] on /dev/ttyUSB0 - Sent : 0D,00,00,00,00,00,00,00,00,00,00,00,00,00 2023-02-12 03:25:04.511 [rfxcom] on /dev/ttyUSB0 - Sent : 0D,00,00,01,02,00,00,00,00,00,00,00,00,00 2023-02-12 03:25:04.525 [rfxcom] on /dev/ttyUSB0 - Received: 14,01,00,01,02,53,1C,00,02,00,00,01,03,1C,04,52,46,58,43,4F,4D 2023-02-12 03:25:04.527 [rfxcom] on /dev/ttyUSB0 - Sent : 0D,00,00,02,07,00,00,00,00,00,00,00,00,00 2023-02-12 03:25:04.811 [rfxcom] on /dev/ttyUSB0 - Received: 14,01,07,02,07,43,6F,70,79,72,69,67,68,74,20,52,46,58,43,4F,4D 2023-02-12 03:25:04.812 [rfxcom] on /dev/ttyUSB0 - Copyright RFXCOM 2023-02-12 03:25:04.813 [rfxcom] on /dev/ttyUSB0 - Started command message queue Device initialised 2023-02-12 03:25:04.815 [rfxcom] on /dev/ttyUSB0 - Queued : 0A,14,00,03,06,96,B1,01,01,1F,00 2023-02-12 03:25:04.816 [rfxcom] on /dev/ttyUSB0 - Queued : 0A,14,00,04,06,96,B1,01,01,1F,00 2023-02-12 03:25:04.817 [rfxcom] on /dev/ttyUSB0 - Queued : 0A,14,00,05,06,96,B1,01,01,1F,00 2023-02-12 03:25:04.820 [rfxcom] on /dev/ttyUSB0 - Sent : 0A,14,00,03,06,96,B1,01,01,1F,00 2023-02-12 03:25:04.821 [rfxcom] on /dev/ttyUSB0 - Sent : 0A,14,00,04,06,96,B1,01,01,1F,00 2023-02-12 03:25:04.821 [rfxcom] on /dev/ttyUSB0 - Sent : 0A,14,00,05,06,96,B1,01,01,1F,00 2023-02-12 03:25:05.531 [rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,03,00 2023-02-12 03:25:05.532 [rfxcom] on /dev/ttyUSB0 - Response: Command message 03, ACK - transmit OK 2023-02-12 03:25:06.233 [rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,04,00 2023-02-12 03:25:06.234 [rfxcom] on /dev/ttyUSB0 - Response: Command message 04, ACK - transmit OK 2023-02-12 03:25:06.938 [rfxcom] on /dev/ttyUSB0 - Received: 04,02,01,05,00 2023-02-12 03:25:06.939 [rfxcom] on /dev/ttyUSB0 - Response: Command message 05, ACK - transmit OK



Could it be that something in the protocol has changed? I find that really unlikely as I don't think that the LightwaveRF switches themselves could be flashed by the hub as they seem to be pretty simple/dumb devices. Therefore I'm wondering if this could be something like a bug with the lib itself?

maxwellhadley commented 1 year ago

I assume you have recently updated node-rfxcom to the recent version 2.5.0 - is that right? The Lighting5 transmitter hasn't been touched for 3 years, so nothing should have changed there. The bytes being sent to the RFXtrx433e are correct, and it acknowledges transmission, so the issue doesn't look to me like a problem with the Javascript code.

Some questions:

Have you recently updated the RFXtrx433e firmware? Did it work before that time?
Can you successfully send a command to any other (non-lightwaveRF) device using the RFXtrx433e?
Are you receiving messages (from anything) using the RFXtrx433e? It looks like you did, but I'm not clear if that was before or after the problem started

Things to try:

Check the RFXtrx433e aerial is connected, and the securing nut is (hand) tight, and that hasn't accidentally dropped down inside something metal that might block RF. I think this is unlikely if you are receiving messages with RSSI 7 though.
Try sending a message to any other non-lighting5 type device you may have access to & see if it works
Downgrade the RFXtrx433e to a previous version

To me, it looks like the transmitter hardware in your RFXtrx433e might have failed, or just possibly version 1047 may have introduced a new problem with LightwaveRF transmission - I don't have anything appropriate here to test with.

Incidentally, it looks like you aren't going about mood & level setting correctly: the README is out of date! It should be like this now:

rfxtrx.initialise(function () {
    console.log("Device initialised");
    lightwaverf.switchOn("0x0696B1/1");
    lightwaverf.setMood("0x0696B1/1", 0x03);
    lightwaverf.setLevel("0x0696B1/1", 0x10);
});

I introduced this change a very long time ago, when additional subtypes were added that needed a different way to set parameters. But it seems I forgot to update this part of the README (which I actually 'inherited' from the original package maintainer)

maxwellhadley commented 1 year ago

Just a quick update - I tried sending your LightwaveRF command from an RFXtrx433e using firmware 1047 Pro 1, and receiving it on an RFXtrx433 running firmware 1028 type 2 (the most recent supported). That worked, as did the other way round. It looks like you might have a hardware failure :(

kevinkga commented 1 year ago

Yes I used the latest version of the npm package.

I initially I tried with the stock firmware from factory as it all worked at some point. However, after encountering this issue I tried several different firmware versions just to eliminate that possibility (from oldest to newest) but no luck at all.

I only have a Louvolite blinds remote control R170 remote handy to test sending but i don't know what protocol that uses. I also couldn't sniff any data from it using the 'receive' event so I'm really not sure and, like you, I suspect a hardware issue.

Thanks for clarifying the function parameters. I'll admit that this confused me too a little as i couldn't find the params in the sources.

I would gladly buy a replacement Rfxcom RFXtrx433e unit but they don't seem to make them anymore :(

Would you know of any alternative hardware that could work instead? I see some chinese 'clones' on AliExpress but I'm not sure they'd work.

maxwellhadley commented 1 year ago

Louvolite is type BLINDS_T0 and uses the Blinds1 transmitter object. It's a funny protocol, and if you enable BLINDS_T0 reception using RFXmgr it stops the reception of all other protocols - but may be worth it for a test, to find out the address of your Louvolite motor, then see if you can can transmit to it.

RFXCOM are in the process of introducing a new product line, to get round the chip shortages that have been hitting everyone lately. If you can find somewhere that has the RFXtrx433XL in stock, that would be OK, or hang on for the new units.

You might do better buying a cheap wireless controlled socket, like a HomeEasy, to confirm your transmitter really is faulty, before spending on a new one (no matter how shiny!)

kevinkga commented 1 year ago

Just to summarise: I have decided to purchase the XL unit as I have concluded that this is not an issue with the this library but rather a hardware issue with my device. There's luckily a Swiss retailer that has them in stock

rfxcom / node-rfxcom

LightwaveRF implementation not working #111