Changing batteries

No, this is not regarding the batteries of my motion sensors 🙂 Those are still running fine since July 29th (3 months); this is about my Oregon Scientific Temp/Hygro Sensors. These sensors are nice; they look good, they have a LCD display which is also useful, and as long as you don’t have too much of them, reception is reasonably good too. However, sometimes, when 2 sensors transmit at exactly the same time, one sensor can prevent another one from being received, but after a day or so this issue resolves itself. I can live with that for now. A more irritating “feature” of these Oregon sensors is that when the batteries are empty and they’ll have to be replaced, the address with which you can distinguish between sensors, changes. That’s not handy, because then you have to change a key value in your running Domotica application.

OS Temp/Hygro Sensor

In my Domotica application, all devices are represented by objects which reside in memory. And when the RFXCOM 433 MHz receiver detects a new incoming OS (Oregon Scientific) packet, it evaluates the packet to get the address and then forwards the complete packet to the corresponding object with that same address. (BTW, this is the only way to efficiently filter duplicate packets, for which all OS & X10 sensors are well known; send an identical packet many times and hope that at least one of them will be received…)

In the past, when I changed the batteries on a OS sensor, I had to look in my ‘valid but unprocessed sensor packet log’ to see what the new address had become, change this value in the database and restart my Domotica app. Not a very smart thing to do; so I changed this procedure a few months ago.  I added a new Reload method (called a procedure or function in Delphi) to the Device class of which all other device classes are inherited from. This method does nothing more then a complete reload of the ‘static’ information that is stored in the database: things like the Description, Location, Enabled and some more parameters that control the general behavior of a Device. And, of course, the Address is being refreshed.

This refreshing of the Address results in no longer having a Device object in memory with the old Address, but with the new one; new incoming packets are processed again and I don’t have to restart the complete app anymore: life goes on! All with the click of a button on some device management page on my website. Cool. However, I do still have to manually edit the Address in the database.

Next thing I want to try is make this even more ‘intelligent’ (a synonym for ‘automated’? :-)) : i mean, whenever a specific sensor hasn’t been received for a specific amount of time and another sensor with a new Address (of the same type) suddenly appears, would it be doable to do all this changing of Addresses all by itself? Of course! But, it’s also potentially dangerous; I don’t want my database getting messed up automatically cause that wouldn’t very intelligent!

Another issue is that this has to be dealt with on Interface level, cause that’s where all packets are ‘seen’ before they are distributed and therefore it’s the only place where such decisions can be made. And this goes against my wish to keep an interface class as stupid as possible… OK, maybe I’ll just leave it as it is now…

Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *