Closed Sherulez closed 5 years ago
This might be related to some recent issues with the serialport
package. They published an update to version 7.1.2 yesterday: can you run npm outdated
in the node-red-contrib-rfxcom
install directory and see what you have? They may have fixed it - or, of course, they may have just introduced the bug.
I don't have a Windows 10 system here to test on, and in fact I don't regularly test on Windows - I have been relying on serialport
to work properly across platforms.
Thank you for your reply. Before I used a raspberry for all that (and it worked very well) but as he died, waiting to receive my RPI 3B + I must fight with Windows :(
npm outdated
gives me this :
C:\Users\Julien\.node-red\node_modules\node-red-contrib-rfxcom>npm outdated
Package Current Wanted Latest Location
rfxcom MISSING 1.4.1 2.0.0 node-red-contrib-rfxcom
As I am not very good in the npm package world and the "MISSING" intrigued me, I did an npm update
and then have this :
Package Current Wanted Latest Location
rfxcom 1.4.1 1.4.1 2.0.0 node-red-contrib-rfxcom
But I still have the same problem.
A npm ls
gives me this :
[...]
`-- rfxcom@1.4.1
+-- queue@4.5.1
| `-- inherits@2.0.3
`-- serialport@7.1.2
+-- @serialport/binding-mock@2.0.4
| +-- @serialport/binding-abstract@2.0.4
[...]
It looks like I already have serialport 7.1.2 if I understand correctly ?
PS: I found this https://discourse.nodered.org/t/not-possible-to-communicate-via-com-port-with-rfxcom/1909 Someone who seems to have the same problem as me (as of last July)
Yes, you have the latest version of serialport, and the most recent version of node-rfxcom supported by the current node-red-contrib-rfxcom (which is due for an upgrade in the next few days). I don't understand the MISSING message though - it would seem to mean you didn't have node-rfxcom installed at all, which would have given you a different error entirely.
Please can you cd to the installation directory of rfxcom
and try:
npm run find-rfxcom
This will search for RFXCOM devices on all system serial ports as returned by the serialport
package. If it hangs (and returns a 'port in use' error when you ^C out of it), then the serialport error which was present in 7.1.1 is still there in 7.1.2. If you get the same errors you saw from NodeRED, it is probably a different issue
Scanning for RFXCOM devices...
None found
Looks like my RFX is not found. (It's very strange, knowing that windows detects it well (it is listed in COM and LPT) my VCP drivers are up to date and the RFXMngr works fine.
I did a clean install of node and npm, then I just installed rfxcom and its dependencies. Then I launched this with node :
var rfxcom = require('rfxcom');
var rfxtrx = new rfxcom.RfxCom("COM8", {debug: true});
rfxtrx.initialise(function () {
console.log("Device initialised");
});
And I have this output :
9 Jan 23:35:46 - [rfxcom] on COM8 - Sent : 0D,00,00,00,00,00,00,00,00,00,00,00,00,00
9 Jan 23:35:46 - [rfxcom] on COM8 - Sent : 0D,00,00,01,02,00,00,00,00,00,00,00,00,00
9 Jan 23:35:47 - [rfxcom] on COM8 - RFXtrx433 disconnected from COM8
9 Jan 23:35:47 - [rfxcom] on COM8 - Cleared command message queue
I have less information but the initialization does not seem to succeed. It seems to be a problem related to rfxcom
/ serialport
. I may have to try to create an issue on their github ?
I am also a maintainer of rfxcom
- I will take a look at it there when I get a chance
Ok, thank you for your time.
I have done some tests with System.IO.Ports in .NET and also with only the "serialport" package under node.js to make sure that I am not having problems communicating with my COM port.
Both work well (or at least I get the data bytes of my probes).
[js] :
const SerialPort = require('serialport')
const port = new SerialPort('COM8', function (err) {
if (err) {
return console.log('Error: ', err.message)
}
});
port.baudRate = 38400;
port.on('data', function (data) {
console.log('Data:', data)
})
port.on('error', function(err) {
console.log('Error: ', err.message)
});
[Output] :
C:\Users\Julien\Desktop\rfxcom-test>node sp.js
Data: <Buffer 4a>
Data: <Buffer 8b ff>
Data: <Buffer 4a>
Data: <Buffer 8b ff>
Data: <Buffer ca>
Data: <Buffer 03 ff>
Regarding writing, I copied the functions (getRFXStatus()
, _sendMessage()
andtransmit()
) from rfxcom.js and I used them to send a status request to my RFX. It seems to work since I get an answer :
<Buffer 14 01 00 00 02 53 21 00 00 27 00 01 03 ff 05 5a 00 00 00 00 00>
Changing this function in this way in rfxcom.js (v.2.0.0) seems to have "solved" the problem.
I imagine that everything I have quoted is important. So it may not be a perfect solution, but maybe it will give you some insights.
this.on("ready", function () {
console.log("ready");
self.receiving = true;
self.getRFXStatus(function (err) {
if (err) {
self.close();
self.emit("disconnect", err);
}
});
/*self.resetRFX(function (err) {
if (err) {
self.close();
self.emit("disconnect", err);
} else {
setTimeout(function () {
self.flush(function (err) {
if (err) {
self.close();
self.emit("disconnect", err);
} else {
self.receiving = true;
self.getRFXStatus(function (err) {
if (err) {
self.close();
self.emit("disconnect", err);
}
});
}
});
}, 500);
}
});*/
});
Now I have :
C:\Users\Julien\Desktop\rfxcom-test>node index.js
[connecting] Event undefined
ready
[ready] Event undefined
10 Jan 15:54:52 - [rfxcom] on /COM8 - Sent : 0D,00,00,00,02,00,00,00,00,00,00,00,00,00
10 Jan 15:54:52 - [rfxcom] on /COM8 - Received: 14,01,00,00,02,53,21,00,00,27,00,01,03,FF,05,58,00,00,00,00,00
[receive] Event 20,1,0,0,2,83,33,0,0,39,0,1,3,255,5,88,0,0,0,0,0
[status] Event [object Object]
{ subtype: 0,
seqnbr: 0,
cmnd: 2,
receiverType: '433.92MHz transceiver',
hardwareVersion: '1.3',
firmwareVersion: 1033,
firmwareType: 'Pro 1',
enabledProtocols: [ 'X10', 'ARC', 'AC', 'OREGON' ],
transmitterPower: 10,
noiseLevel: 88 }
10 Jan 15:54:52 - [rfxcom] on /COM8 - Sent : 0D,00,00,01,07,00,00,00,00,00,00,00,00,00
10 Jan 15:54:52 - [rfxcom] on /COM8 - Received: 14,01,07,01,07,43,6F,70,79,72,69,67,68,74,20,52,46,58,43,4F,4D[receive] Event 20,1,7,1,7,67,111,112,121,114,105,103,104,116,32,82,70,88,67,79,77
[receiverstarted] Event Copyright RFXCOM
10 Jan 15:54:52 - [rfxcom] on /COM8 - Copyright RFXCOM
10 Jan 15:54:52 - [rfxcom] on /COM8 - Started command message queue
Device initialised
10 Jan 15:55:39 - [rfxcom] on /COM8 - Received: 08,50,02,06,F1,01,00,54,69
[receive] Event 8,80,2,6,241,1,0,84,105
10 Jan 15:56:18 - [rfxcom] on /COM8 - Received: 08,50,02,07,F1,01,00,54,69
[receive] Event 8,80,2,7,241,1,0,84,105
(Do not take into account additional debug info, it comes from my tests.)
Edit : Apparently the problem comes from the serialPort.flush() which seems to be broken under Windows :
https://github.com/node-serialport/node-serialport/issues/1403 https://github.com/node-serialport/node-serialport/issues/1409 https://github.com/node-serialport/node-serialport/issues/1537
Many thanks for your bug-hunting efforts! It does indeed look like the underlying issue is serialport #1409.
The code you have commented out is part of the logic that ensures robust handling of arbitrary disconnections & reconnections of RFXtrx433 devices, so I don't want to remove it altogether. The flush() is important, as there is no guarantee the RFXtrx433 won't send random data to the host after connection & before the reset is received. I think the best approach is probably to test the platform, and either call flush() or not as appropriate. With a bit of luck the data parser will cope with any spurious data, but if not, the user will have to disconnect & reconnect again.
Hopefully, the serialport guys will sort this out soon (as well as the asynchronous callback issue #1751, for which a pull request awaits merging).
You're welcome. It was not much :)
Indeed I had other problems after removing this part of the function.
I was well connected to the RFX but node-red did not seem to know it was the case since under the sensor-node I had "connecting ..." on the other hand I receive the data well. So I ended up just removing the flush like this :
this.on("ready", function () {
self.resetRFX(function (err) {
if (err) {
self.close();
self.emit("disconnect", err);
} else {
setTimeout(function () {
self.receiving = true;
self.getRFXStatus(function (err) {
if (err) {
self.close();
self.emit("disconnect", err);
}
});
}, 500);
}
});
});
Also, when I redeploy my nodes, the COM8 tells me "Access Denied" and I have to redeploy again for it to work.
Now, indeed if I understood you correctly, I expose myself to the risk of receiving corrupted data etc ... and a bad management of disconnections / reconnections.
I also hope that serialport guys can take a look at this problem. Thank you for your time.
It seems the latest fix to serialport has introduced yet another bug, which causes a segfault on macOS & Linux. Version 6.2.2 seems to be the best available at present, but it still has the Windows issue you found.
Rather than publishsing an interim version with a partially-functional workaround (I tested removing the call to flush()
& if definitely goes wrong if you try disconnecting the RFXCOM), I'm inclined to wait a bit until the serialport guys get all their s**t in one sock...
Sorry if this is causing you problems! Normal service will be resumed as soon as possible.
I have now published rfxcom version 2.0.1 - this rolls back to serialport version 6.2.2, while including the partially-functional workaround. You can npm install rfxcom@2.0.1
from the node-red-contrib-rfxcom
install directory to use it.
I'm happy to say serialport@7.1.3
has been released which fixes the segfault issue.
Indeed everything seems to work very well now on my environement:
(customlog): [CONNECTING EVENT]
19 Jan 22:29:20 - [rfxcom] on /COM8 - Sent : 0D,00,00,00,00,00,00,00,00,00,00,00,00,00
19 Jan 22:29:20 - [rfxcom] on /COM8 - Sent : 0D,00,00,01,02,00,00,00,00,00,00,00,00,00
19 Jan 22:29:20 - [rfxcom] on /COM8 - Received: 14,01,00,01,02,53,21,00,00,27,00,01,03,FF,05,57,46,58,43,4F,4D
(customlog): [RECEIVE EVENT] 20,1,0,1,2,83,33,0,0,39,0,1,3,255,5,87,70,88,67,79,77
(customlog): [STATUS EVENT] Event [object Object]
{ subtype: 0,
seqnbr: 1,
cmnd: 2,
receiverType: '433.92MHz transceiver',
hardwareVersion: '1.3',
firmwareVersion: 1033,
firmwareType: 'Pro 1',
enabledProtocols: [ 'X10', 'ARC', 'AC', 'OREGON' ],
transmitterPower: 10,
noiseLevel: 87 }
19 Jan 22:29:20 - [rfxcom] on /COM8 - Sent : 0D,00,00,02,07,00,00,00,00,00,00,00,00,00
19 Jan 22:29:20 - [rfxcom] on /COM8 - Received: 14,01,07,02,07,43,6F,70,79,72,69,67,68,74,20,52,46,58,43,4F,4D
(customlog): [RECEIVE EVENT] 20,1,7,2,7,67,111,112,121,114,105,103,104,116,32,82,70,88,67,79,77
19 Jan 22:29:20 - [rfxcom] on /COM8 - Copyright RFXCOM
19 Jan 22:29:20 - [rfxcom] on /COM8 - Started command message queue
(customlog): [DEVICE INITIALISED]
Thank you so much ! And especially thank you for the time and energy you give us to offer this kind of packages / applications
Hello,
I am currently experiencing a problem with the communication between my "RFXtrx433E" and this contrib. To begin here the details of my setup :
My RFX is connected on the COM8 and it is well detected by the RFXmngr (I also receive the packets).
But in the node-red debug output console I got this :
etc ...
In my
rfxtrx-port
node I simply write "COM8" for theSerial port
. The problem may come from there ? Any help would be very appreciated.