Decoding update
Page 1 of 1
Decoding update
Hi guys,
I've just had to make a change to the RFXtrx433 decoding for a couple of 'types'.
Previously, device strings appeared as follows: -
0x[type]:[subtype]-xx[2nd ID byte].
For the sensors i'd tested, the xx value was a random byte assigned each time the device was 'reset' and/or had its batteries changed.
The 2nd byte was linked to the unique channel ID assigned to each sensor.
So in the interests of simplicity, i chose to 'wildcard' the random byte, so that when you reset the sensor (or renew batteries), you wouldn't have to worry about the full 'ID' changing (and you could continue as normal).
This has worked fine for past year or more, however one of our users (thanks pete252) has brought to my attention that some sensors, which are a clone of the TFA/Cresta brand are actually using the 1st byte of the ID to denote the unique channel.
So, i've implemented a fix (available using core >= 1.011) which now presents the full ID (xxxx) in the devices ID string.
It's a shame this had to be implemented, because now, when you reset a sensor (or change them batteries), the same sensor will have a new ID and you'll need to update the 'parameter' section for the particular data point, so they match.
Thanks
Neil
I've just had to make a change to the RFXtrx433 decoding for a couple of 'types'.
Previously, device strings appeared as follows: -
0x[type]:[subtype]-xx[2nd ID byte].
For the sensors i'd tested, the xx value was a random byte assigned each time the device was 'reset' and/or had its batteries changed.
The 2nd byte was linked to the unique channel ID assigned to each sensor.
So in the interests of simplicity, i chose to 'wildcard' the random byte, so that when you reset the sensor (or renew batteries), you wouldn't have to worry about the full 'ID' changing (and you could continue as normal).
This has worked fine for past year or more, however one of our users (thanks pete252) has brought to my attention that some sensors, which are a clone of the TFA/Cresta brand are actually using the 1st byte of the ID to denote the unique channel.
So, i've implemented a fix (available using core >= 1.011) which now presents the full ID (xxxx) in the devices ID string.
It's a shame this had to be implemented, because now, when you reset a sensor (or change them batteries), the same sensor will have a new ID and you'll need to update the 'parameter' section for the particular data point, so they match.
Thanks
Neil
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum
|
|