Q: Undefined topic?

[TotallyInformation]

Hi Max, sorry to bother you again. As I've been trying to refactor my HA system, I created a new set of flows that capture all the inputs from all of the rfxcom nodes. In doing so, I've come across some strange entries in the log.

Most entries have a topic that starts with the device type, e.g. CM119_160, LIGHTWAVERF, etc. but I now have a few that start with "undefined" - any idea what these could be? I'm pretty sure they aren't mine and the only thing they report is an RSSI.

I dumped the following from MQTT_Spy. Note that I add "RFX//" to the beginning of the topic. I've also added a timestamp and msgKeys to the payload. There is no payload from rfxcom.

RFX/Lights/undefined/0x00112C/15
{"status":{"rssi":3},"timestamp":"2017-08-02T09:44:29.683Z","msgKeys":["status","topic","_msgid","origTopic","timestamp"]}

RFX/Lights/undefined/0x009111/17
{"status":{"rssi":4},"timestamp":"2017-08-02T10:51:55.593Z","msgKeys":["status","topic","_msgid","origTopic","timestamp"]}

RFX/Lights/undefined/0x001111/17
{"status":{"rssi":3},"timestamp":"2017-08-03T06:24:05.699Z","msgKeys":["status","topic","_msgid","timestamp"]}

RFX/Lights/undefined/0x001145/2
{"status":{"rssi":3},"timestamp":"2017-08-03T09:21:41.814Z","msgKeys":["status","topic","_msgid","timestamp"]}

By comparison, here is the output generated by my door sensor - with extra metadata added by my flow (gotta love JSONata!):

RFX/Lights/LIGHTWAVERF/0xF4C36F/10
{"status":{"rssi":3},"payload":"On","timestamp":"2017-08-03T17:36:10.354Z","meta":{"location":"HOME/IN/00/FRONTDOOR","type":"Mag","description":"Siemens Magnetic Door Sensor"},"msgKeys":["status","topic","payload","_msgid","timestamp"]}

[maxwellhadley]

This is happening because the RFXtrx is receiving transmissions from devices with a known packet type, but with a subtype that has been added to the firmware since the underlying node-rfxcom library was last updated. Consequently it doesn't have a name for the subtype - which is why you get 'undefined' - and it doesn't know what the command (number) from node-rfxcom is supposed to mean for this subtype (since they vary quite a bit) - which is why there is no payload.

I've been working on node-rfxcom recently, and I'm very close to publishing a major update which supports very nearly everything the RFXtrx433 itself does, so the problem should go away soon. But I ought to modify node-red-contrib-rfxcom so that it returns a topic like PACKET_TYPE_0x12_UNKNOWN_SUBTYPE/0x1234/5 in a situation like this. Not having a message payload at all in this situation is probably the best thing to do though.

[TotallyInformation]

Ah, thanks for that Max. That'll be because I just got round to updating my firmware! I suspected as much but just wanted to make sure it wasn't something else.

Some kind of indicator in the topic would be nice though that is a little long ;-)

I have to admit to now being really nosy because I'm receiving all sorts of device output and I really didn't expect to get so much, I certainly didn't last time I checked. Fascinating to see people's power usage and the temperatures of their smart-fridges and freezers (I assume that's what is returning the 2 deg C (humidity 0) and -18 deg C returns). There is one that is returning 30 deg C which intrigues me, terrarium? boiler? There is one on TH9 returning 1.7 deg C with humidity 192% which is strange.

I have 2 on TH9, 3 on TEMP10, 3 CM119_160's and 4 undefined's.

Now I just need to work out why my Nexa doorbell seems to no longer be able to communicate from the front door though it works fine from my office! Annoyingly no battery reports from the bell nor from the 2 LightwaveRF mag switches that seem to have become intermittent so it's hard to know if it is just the batteries starting to go.

[maxwellhadley]

I've just published version 1.4.3 to npm which should give you a topic like LIGHTING5_UNKOWN/0x00112C/15 or the equivalent for other packet types, where the subtype is currently unknown. I've also just published an update to node-rfxcom which fixes an obscure and long-standing initialisation bug that someone recently managed to provoke!

Please let me know if this works for you & I will close this issue if it does

[TotallyInformation]

Hi Max, I did try the update last night and then regretted it! I was getting output with no ID in the topic.

RFX/Sensor/TH1
RFX/Lights/LIGHTWAVERF/6

Should have been:

RFX/Sensor/TH1/0xCE01
RFX/Lights/LIGHTWAVERF/0xF30F69/6

The 1st 2 parts have been added by me of course but I confirmed this with a debug node attached directly to the input (sorry, I didn't capture that - it was after midnight :)

[maxwellhadley]

Oops! Sorry about that - the string catenation operator has lower precedence than logical OR, despite what I thought. Brackets added in the appropriate places to fix it, I hope. Version 1.4.4 published to npm.

[TotallyInformation]

:-)

No problem. OK, I've updated again and all seems to be working. I only get the external messages occasionally so it may be a while before I get some more updates.

[maxwellhadley]

OK thanks. I have noticed that recent firmware updates have been giving me the odd unrecognised message, as well. I think the threshold sensitivity has been reduced a bit, so that some of these are actually spurious random noise, although they do seem repeatable - I have only a few close neighbouring houses where they might be coming from. I have two RFTtrx433's, and if they are both on and within a few cm of each other the number of mysterious messages increases. The latest firmware update may possibly have fixed this (I'm still on 1017 at the moment)