Closed basvdijk closed 6 years ago
I'm working on it... https://github.com/rfxcom/node-rfxcom/tree/use-serialport-6
Great! I noticed it because Rfxcom doesn't build anymore on Node 10 on my RPI3 and with it my home automation didn't work anymore :) 👍
I've just tested the use-serialport-6 branch and it looks it works :) Is there a reason why it wasn't released yet?
It needs proper testing on Windows & Linux as well... Also the packets are being converted from Buffers to Arrays and back twice, at the moment - but I think I know how to fix that now.
On Linux, can you please test that unplugging the RFX & plugging it back in again is handled properly? You should see the node status indicators change & everything should just recover when plugged in. Also, starting Node-RED with the RFX disconnected & then reconnecting should just work.
(They have changed some of the Serialport events I use for this)
Do you have an example test repo/code I should run? Inside my home automation system it is not possible to really test this.
Not really - I just try and break it by randomly plugging & unplugging. FYI it is definitely not working properly, it is getting its knickers in a right twist if you disconnect & reconnect the RFX. This used to work perfectly with the old serialport! The sequence of emitted events has definitely changed
Weird, I was hoping just updating the package would just be enough :/ Any luck by checking the changelog of serialport between v2 and v4? I found https://github.com/node-serialport/node-serialport/blob/master/UPGRADE_GUIDE.md
I think it was the change from 4 to 5 that broke it. It looks as if the serialport keeps sending the same bytes to the parser multiple times, probably depending on how many times the serialport.open() call fails while the RFX is disconnected. The call is retried every few seconds
I am starting to suspect a Serialport bug. I'll try to create a simple example that provokes it & raise an issue if I can do so.
Would be great if you could tackle a bug, will help a lot of other projects depending om serialport :)
I am having great difficulty trying to pin this problem down (on MacOS). Sometimes it works, sometimes it doesn't - it seems to depend on the past history of use of the tty.usbserial device. I cannot generate a reproducible failure so I can raise an issue with Serialport. The best way of getting good operation appears to be to always reboot the computer (!) after connecting the RFXtrx. The old robust plug/unplug behaviour no longer works. Occasionally, it will get into a state where it can receive messages from the RFXtrx but not send commands - the Serialport write() literally fails to work.
Do you think this MacOS specific? I am using a RPI3 (Raspian)
I think it most probably is binding-specific, but I am unable to make any progress at the moment. If you can test the latest comit on RPi, that would be useful. The behaviour when unplugging/plugging the RFXtrx is the key point.
I think I have found the underlying issues:
error
event as well as the close
event (otherwise you just get the close
event)The combination of the two was enough to completely confuse the disconnect/reconnect logic. I wrote a special test program, and used a USB serial lead with a loopback connection between the TxD & RxD pins. Otherwise I would never have tracked this down. Hopefully I will have time to implement the fix soon.
Wow, really impressive how you figured this out! Looking forward to your implementation :)
I have just pushed a commit to the use-serialport-6 branch which seems to have fixed the connect/disconnect issue: but only tested on MacOS so far.
Finally! Version 1.4.0 published to npm.
Latest version is 6.2.0, in the package.json is still referred to 4.*