startup problems......

[bwired-nl]

Hi Kevin If I start the nodejs in 30% of the cases i get below if i stop and start again after this it works always on second start do you see this also sometimes, or only in my case thnaks Pieter

pi@raspberrypi ~ $ node testrfx Sent : 0D,00,00,00,00,00,00,00,00,00,00,00,00,00 Sent : 0D,00,00,01,02,00,00,00,00,00,00,00,00,00 Device initialised Received: 00 Unhandled packet type = 00 Received: 00 Unhandled packet type = 00 Received: 00 Unhandled packet type = 00 Received: 00 Unhandled packet type = 00 Received: 00 Unhandled packet type = 00 Received: 00 Unhandled packet type = 00 Received: 00 Unhandled packet type = 00 Received: 00 Unhandled packet type = 00 Received: 00 Unhandled packet type = 00 Received: 00 Unhandled packet type = 00

[bigkevmcd]

It looks like the initialisation isn't right.

How are you creating / initialising the rfxcom library / device?

Also what platform? I guess it could be not flushing successfully?

[njh]

Hello,

I have been experiencing this too. Seems to be some kind of synchronisation problem.

Sent from my phone

On 24 Feb 2014, at 15:53, bwired-nl notifications@github.com wrote:

Hi Kevin If I start the nodejs in 30% of the cases i get below if i stop and start again after this it works always on second start do you see this also sometimes, or only in my case thnaks Pieter

pi@raspberrypi ~ $ node testrfx Sent : 0D,00,00,00,00,00,00,00,00,00,00,00,00,00 Sent : 0D,00,00,01,02,00,00,00,00,00,00,00,00,00 Device initialised Received: 00 Unhandled packet type = 00 Received: 00 Unhandled packet type = 00 Received: 00 Unhandled packet type = 00 Received: 00 Unhandled packet type = 00 Received: 00 Unhandled packet type = 00 Received: 00 Unhandled packet type = 00 Received: 00 Unhandled packet type = 00 Received: 00 Unhandled packet type = 00 Received: 00 Unhandled packet type = 00 Received: 00 Unhandled packet type = 00

— Reply to this email directly or view it on GitHub.

[bwired-nl]

starting from a Rasp rfxtrx = new rfxcom.RfxCom("/dev/ttyUSB0", {debug: true}); and use the standard rfxcom.js i tried to increase the delaytimer but no luck But you dont have that problem?

[bigkevmcd]

try...

var rfxtrx = new rfxcom.RfxCom("/dev/ttyUSB0", {debug: true}); rfxtrx.initialise(function () { don't do anything else 'til this has completed... });

[bigkevmcd]

If this sorts it, I guess I need to improve the documentation ;-)

[bwired-nl]

i got you :-) rfxtrx.on needs to be in this function

[bigkevmcd]

Not necessarily, you can set up the event listeners, then call .initialise(...)

[bwired-nl]

can you give a sample

[bigkevmcd]

https://github.com/bigkevmcd/node-rfxcom/wiki/Using-node-cron

[bwired-nl]

still sometimes problems

Sent : 0D,00,00,00,00,00,00,00,00,00,00,00,00,00 Sent : 0D,00,00,01,02,00,00,00,00,00,00,00,00,00 Received: 00 Unhandled packet type = 00 Received: 00 Unhandled packet type = 00 Received: 00 Unhandled packet type = 00

[bigkevmcd]

Hmmm...that's odd, guess it could be something in the buffer, lemme have another look at the initialisation logic.

[bwired-nl]

I kevin i check the complete initialize based on the SDK and the sequence you are following seems to be right! I tried to put some extra delays in etc but same problem. Perhaps the only solutions is to check the first received data after Init. :if this is Received: 00 then directly do the reset again, try this 3 times and the stop the program

Sent : 0D,00,00,00,00,00,00,00,00,00,00,00,00,00 Sent : 0D,00,00,01,02,00,00,00,00,00,00,00,00,00 Received: 00

what i see now i that if this goes wrong i do ctrl-c and immidialtly restart the again, it everytime works on second try. Also it looks like the longer you wait the worse it gets, can have something to do with the buffer of the rfxtrx. i have many sensors data coming in.

[bigkevmcd]

I guess the issue could be that there's unavoidable data hitting the device during the initialisation period, some of which is being dropped.

I suspect flagging the first "correct" package that we've received, and discarding 'til then might work.

https://speakerdeck.com/bigkevmcd/domotica-with-node-dot-js <- might interest you.

[bwired-nl]

in the SDK After the reset The RFXCOM will now stop the RF receive for 10 seconds if its goes wrong it does not correct itself, keep receiving like below Nice presentation!!

Received: 00 Unhandled packet type = 00 Received: 00 Unhandled packet type = 00 Received: 00 Unhandled packet type = 00 Received: 00 Unhandled packet type = 00

[bigkevmcd]

Just to clarify, it's basically hanging during startup for you? If so, that's a bit more critical...

[bwired-nl]

yes only when i start the program (njh has the same problem) once it is started good, its running very smoothly but if it goes wrong it never corrects itself, you have to restart

[maxwellhadley]

I've just hit this problem on the Beaglebone black. Immediately terminating & restarting node fixed it:

root@beaglebone:~/RFXtrx433# node test Sent : 0D,00,00,00,03,53,00,00,00,00,00,00,00,00 Sent : 0D,00,00,01,00,00,00,00,00,00,00,00,00,00 Sent : 0D,00,00,02,02,00,00,00,00,00,00,00,00,00 Device initialised Received: 00 Unhandled packet type = 00 ^Croot@beaglebone:~/RFXtrx433# node test Sent : 0D,00,00,00,03,53,00,00,00,00,00,00,00,00 Sent : 0D,00,00,01,00,00,00,00,00,00,00,00,00,00 Sent : 0D,00,00,02,02,00,00,00,00,00,00,00,00,00 Device initialised Received: 0D,01,00,02,02,53,47,00,0C,2F,01,01,00,00 Status message Subtype: 0 Sequence number: 2 Command: 2 Receiver Type: 433.92MHz transceiver Firmware Version: 71 Enabled Protocols: HIDEKI LACROSSE X10 ARC AC HOMEEASY OREGON

[bigkevmcd]

@maxwellhadley Can you paste a minimal bit of code?

I'm trying to reproduce this just now, and getting nowhere.

[bigkevmcd]

Am curious about whether or not it only bites on Raspberry Pi machines.

[maxwellhadley]

Minus a couple of uncalled event handlers, this is my current 'test program':

var rfxcom = require('rfxcom');

var rfxtrx = new rfxcom.RfxCom("/dev/ttyUSB0", {debug: true}), lighting2 = new rfxcom.Lighting2(rfxtrx, rfxcom.lighting2.AC);

rfxtrx.initialise(function (error) { if (error) { throw new Error("Unable to initialise the rfx device"); } else { console.log("Device initialised"); } });

rfxtrx.on("lighting2", function (evt) { console.log("Lighting 2 message"); console.log("Subtype: " + evt.subtype); console.log("Sequence number: " + evt.seqnbr); console.log("ID: " + evt.id); console.log("Unit code (channel): " + evt.unitcode); console.log("Command: " + evt.command); console.log("Level: " + evt.level); console.log("Signal strength: " + evt.rssi); console.log("");

    if (evt.id === "0x001EF1CE" && evt.unitcode === 16) {
        if (evt.command === "On") {
            lighting2.switchOn("0x000BC5DE/4");
        } else {
            lighting2.switchOff("0x000BC5DE/4");
        }
    }
});

rfxtrx.on("status", function (evt) { console.log("Status message"); console.log("Subtype: " + evt.subtype); console.log("Sequence number: " + evt.seqnbr); console.log("Command: " + evt.cmnd); console.log("Receiver Type: " + evt.receiverType); console.log("Firmware Version: " + evt.firmwareVersion); console.log("Enabled Protocols:"); for (var n = 0; n < evt.enabledProtocols.length; n++) { console.log(" " + evt.enabledProtocols[n]); } console.log(""); });

I'm looking to build a node-RED node to encapsulate your package so I'm currently trying to get my head round a good way to present an API to the rest of node-RED. Do you have plans to change your API by way of celebrating a 1.0.0 release? :-)

Max

[maxwellhadley]

More information: root@beaglebone:~/RFXtrx433# uname -a Linux beaglebone 3.8.13 #1 SMP Thu Sep 12 10:27:06 CEST 2013 armv7l GNU/Linux

serialport appears to be version 1.3.1

[bigkevmcd]

Can you try the changes in https://github.com/bigkevmcd/node-rfxcom/tree/drop-zero-length-bytes ?

This drops 0 bytes when we haven't seen a length yet (or at least, a length > 0)

[maxwellhadley]

I've manually copied the changes in this commit onto the BBB (not set up to git direct yet) and the result is I now receive no data

root@beaglebone:~/RFXtrx433# node test Sent : 0D,00,00,00,00,00,00,00,00,00,00,00,00,00 Sent : 0D,00,00,01,02,00,00,00,00,00,00,00,00,00 Device initialised

[bwired-nl]

i will check also

[bwired-nl]

same here on rasp PI Sent : 0D,00,00,00,00,00,00,00,00,00,00,00,00,00 Sent : 0D,00,00,01,02,00,00,00,00,00,00,00,00,00

[bigkevmcd]

Whoops, let me try that again....

[bigkevmcd]

Ok, hopefully fixed.

One of my theories is that flushing isn't working correctly on some devices.

[maxwellhadley]

Maybe the firmware revision? Robert, what version are you using?

Max

[bwired-nl]

same problem :-(....please one more try :-) i have version 71 firmware Sent : 0D,00,00,00,00,00,00,00,00,00,00,00,00,00 Sent : 0D,00,00,01,02,00,00,00,00,00,00,00,00,00

[maxwellhadley]

Yep, same problem here in Hampshire

[bigkevmcd]

Dang, I ran it in here for a while, and it logged things.

I'm still on an old firmware, partly because I have no Windows machine to update it easily (I can use Mono, but it's non-trivial), and partly because I haven't needed to update it.

Unfortunately, after dark is when I need my rfxcom plugged into the machine that runs with it :-)

The code appears to work for me, which is odd, I'll compare the code against the protocol in case something has changed since it was first written.

[bwired-nl]

which firmware version you have ,I know Bert from rfxcom, made some changes a while back but its a while back :-)

[bigkevmcd]

Just checked, r48...wow, didn't realise I was so far behind.

Guess my first task for tomorrow is upgrading the firmware :-)

[bwired-nl]

LOL yes we got the problem...lets hope thanks Kevin

[maxwellhadley]

I'm signing off for the night now - let's see what happens tomorrow evening!

[bigkevmcd]

Ok, I upgraded to firmware v72, type 1.

I'm running this script https://gist.github.com/bigkevmcd/10044564 and the "drop-zero-length-bytes" branch logs elec2 messages without difficulty.

I am on a Macbook Air at the moment tho'...and I suspect that could be significant...

[maxwellhadley]

Still no joy. I think there is a problem with the fragment: if (requiredBytes === null && data[0] != 00) { requiredBytes = data[0] + 1; } which can evaluate true even if nothing has been pushed to data[]. Then requiredBytes is set to NaN, and the parser locks up. I put some debug in to report requiredBytes, buffer[0], and buffer.length: After startup - requiredBytes: null, buffer[0]: 13, len: 14 Received 1 packet - requiredBytes: NaN, buffer[0]: 11, len: 11 requiredBytes: NaN, buffer[0]: 96, len: 1 The one packet caused 2 data events

[bigkevmcd]

https://github.com/bigkevmcd/node-rfxcom/blob/drop-zero-length-bytes/lib/rfxcom.js#L52

That was changed to use buffer[0] rather than data[0].

[maxwellhadley]

Yes, but the problem is in the next line. Since nothing has yet been pushed into data, data[0] + 1 is NaN

[bigkevmcd]

Doh, didn't push my local changes....try now :-)

[bwired-nl]

perfect for me!

[bigkevmcd]

What I'm theorising is that under some circumstances the input buffer isn't being flushed, so we're getting stray bytes.

This code drops 0-value bytes until we've seen a non-zero byte, and it treats that as the first size byte.

[maxwellhadley]

Working for me. But I only ever saw the original failure once

[bigkevmcd]

In all honesty, this is the worst tested section of the code, something I should rectify :-)

[bigkevmcd]

I'll test the code with the broken version and firmware r72 see if I can reproduce the original bug, and if not, I'm happy to merge and release if you are :-)

[maxwellhadley]

It's a parser - maybe it should be implemented as a 'real' state machine? I do remember wondering what would happen if the first data event contained exactly two complete messages, but I'm not sure why any more...

[bigkevmcd]

Sorry, I've been really busy with this for the past couple of months, I'm going to merge the fix and get a release out.

[maxwellhadley]

Kevin,

I've been doing a lot of work on node-rfxcom recently to support my node-RED node. This includes a lot of API extensions and one minor breaking change (your evt.subtype field was either a number or a string depending on the event handler: I've changed it so it's always a string) as well as refactoring. I think there is still a bug with the parser which I have seen triggered when receiving a mixture of lighting2 & th1 messages. I'll get things straight and send a PR sometime soon, so we can discuss. I'd much rather not perpetuate unnecessary forks if it can be avoided.

Cheers,

Max

Sent from my iPhone

On 16 Jun 2014, at 13:26, Kevin notifications@github.com wrote:

Sorry, I've been really busy with this for the past couple of months, I'm going to merge the fix and get a release out.

— Reply to this email directly or view it on GitHub.

[bigkevmcd]

Max,

Thanks, I was trying to move away from a string for the subtype, to a number, so that it's easier to localise...

Kevni

[bigkevmcd]

Will checkout the node-red stuff, that's on my "If I get a spare day somewhere I should look at this" list :-)