I’m in the process of writing an addon for a SolarMax Power Inverter. These devices only have power when the PV panels are producing. At other times, the ethernet connection isn’t active. I’d like to find a way to avoid openHAB trying to update the data during the night. Is there something already existing in openHAB or should I just embed something like commons-suncalc or Time4J?
Thanks. I was hoping to avoid the poller searching for the device when we know it’s not going to respond. I’m not an openHAB guru, but as I understand things, that kind of logic would have to be implemented in the binding itself. I guess it’s only minimal (debugging) log messages that I’d be saving, so I think I’ll just leave it be.
Beyond “because it feels better” why avoid the polling at night? It doesn’t take any energy from the inverter since it’s Ethernet is shut off and it takes probably an immeasurable amount of energy on the openHAB side.
The problem you will run into is telling the binding when not to poll. The actual hours of sunlight one can expect depends on latitude and the season. You’d almost have to reproduce what the Astro binding does inside your binding. And then we will have two bindings with a lot of the same code, all to save just a smidgen of power and network pinging the inverter when it’s offline.
Rather than trying to solve all problems for all people, I’d recommend letting the people help solve part of the problem for you. This is really how openHAB is designed to work anyway. openHAB already has an Astro binding. So why not just provide a Switch channel to turn on/off the polling. Then let those users who want/need to turn off the polling at night handled it with a simple rule based off of what ever criteria they decide. That would let them use the Astro binding, weather bindings, actual light sensor readings, or any other criteria of their choosing to turn on/off the polling.
This is actually one of the most powerful aspects of openHAB, the ability to bridge between technologies and have them interact. If you unilaterally control when the binding polls the inverter, you shut down the user’s options to really customize the behavior how they want.
As Rich says, there’s no real cost to this. As add-on author you get to decide if you want to update channels with UNDEF - or simply not update them at all. (Users then get a choice of applying ‘expire’ techniques if they want to avoid stale data.)
You can supply a “last successful read” timestamp channel.
And/or a “last read error” timestamp channel.
Another way to look at is as an error recovery issue. You “poll”, presumably get a timeout eventually.
So, what’s next? Maybe it is a “real” transient error, try again soon.
But count failures - after 3? 5? failures you know it ain’t gonna work. You can turn your poll rate down.
How quickly do you need to know when the corpse reanimates again? This might not be an overnight sleep, just a router reboot. This governs your max “reduced poll” period.