Oregon temp sensors

Looking for some suggestions. I have a number of Oregon THGN132ES temperature sensors, picked up by a RFXcom TRX.

Problem 1:
I’m not sure which of them work, or which of them is which. I’ve used them with previous HA systems, and they seem to have a ‘feature’ (issue) that means you have to reset them after changing the batteries, and they then seem to take on a new ID.

So, any tips here would be much appreciated!

Problem 2:
Not completely sure how I (when I’ve identified them) include them in the config generally.

They appear as ‘things’, but (and I realise this is probably part of my greater misunderstanding re things/items) I’m not totally sure which channels I should link to - Default? Follow? Offset? EXEC? JS? Are these predefined channels for this type of ‘thing’, or specific to this device?

You link Items to only those Channels that contain information you care about.

I’ve never seen that dialog before but I manage my Items outside of PaperUI so wouldn’t have had opportunity to.

Offset, EXEC, and JS are ways to define an adjustment to the value returned by the device before assigning it to the Item (a Transformation). I have no idea what Follow is. I’d pick Default to start and maybe experiment with the others to see what happens.

What version of OH are you running?

Very annoying - isn’t it? I have the same issue with that “feature” and asked @martinvw for any solution long time ago:

If I’m right, there is no really convinient way yet to deal with the ID change issue.

From a programmers perspective, there is probably a way to at least support an ID change for a RFXCom-thing if one sensor felt silent for a certain time frame and another “new” sensor of the same type/subype is been discovered newly withing this time frame.

This might solve the issue if just one sensor got the batteries replaced at the same time. But this cannot be done automatically: Imagine if you have weak radio receiption and some sensors occasionally drop off and re-appear later. What if some sensor of your neigbors have been picked up in the meantime? This could mess up your whole RFXCom things in the worst case - right? :wink:

If there would be an option for setting the RFXCom binding into a “Battery/ID change mode” -> then change the battery of a single sensor and let the Binding learn the new ID could solve this. But I’m not a programmer. Maybe Martin can think about this again :wink:

Without having such functionality yet I’m doing this for the time being:

The binding is set to “disableDiscovery=true” usually to avoid flooding the inbox with unwanted stuff from the neighborhood.
When I have to change a battery, I revert the setting to “disableDiscovery=false”, put fresh batteries in and check the inbox. If some sensor of the same type appears, I pick it’s ID and edit the ID of the yet existing thing for the “old” sensor. So I can keep all the dependencies (channel, items …).

Btw.: Same works of corse if you raise the debug level of the binding and grep your log for new (unknown) ID’s of your Oregon sensors.

Yes, that’s not quite handy.
Would love having a more convenient procedure for such recurring task …

1 Like

V 2.4.0~20180929170635-1

there’s probably an update I should upgrade to I guess…

Thanks for this! I’m glad it’s not just me :slight_smile: Mine are the solar ones as well, which I’m fairly certain are just the normal ones with a pretend solar panel on them :wink:

This is the other issue I have with them… what’s the best way of limiting the decimals here?

2 ways:

In the widget, in the format field enter %.1f °C

Or in the item file format your item like this:

Number:Temperature   OregonTemp                 "Oregon Temp [%.1f °C]"                <temperature>   (Weather)               { binding }

and in the widget tick the sever-provided format box

1 Like

Not necessarily. I only asked to determine if you were on the newest in which case this may be a new and as yet undocumented feature. Since you are on the snapshots that may be the case. I’ve never seen that dialog before but if it does what I think it does it means my long desired wish to have a generic transformation service might be in the works.