Page 1 of 1
HB startup Ocelot input state...
Posted: Sun Jan 20, 2008 6:28 pm
by Timoh
When HB starts up, is it supposed to set the inputs to their correct state so they match the inputs on the Ocelot?
For example, if a shutdown HB, open my garage door, and restart HB, HB still shows my door as being closed. Closing my door and opening it will change the input as expected.
Thanks
Tim
Posted: Mon Jan 21, 2008 9:29 pm
by ScottBot
When HB starts, it queries the real-time buffer in the Ocelot to get the current input states. It then uses this as the baseline for changes going forward (to compare to changes in buffer for notifications).
Unfortunately, if you changes something while HB is down, that will be the new state when HB is restarted, and it WON'T send notification to the HB devices if different.
Posted: Tue Jan 22, 2008 1:21 pm
by Timoh
If I understand correctly, HB will read the Ocelot input states at startup for references *only*. It will then only change the HB device state upon change from this baseline.
Would there be any drawbacks to actually setting the HB device states based on that first read from the Ocelot?
Tim
Posted: Tue Jan 22, 2008 1:46 pm
by ScottBot
Timoh wrote:Would there be any drawbacks to actually setting the HB device states based on that first read from the Ocelot?
Yes. If you have tasks that fire when a PV changes, they would all go off when HB is restarted (assuming something changed). Now in some cases that may be ok, but on others you would have things happening that were supposed to have happen when the PV changed instead of when the server was started, which is probably not what you wanted.
I like to play it safe and take the conservative approach. There's no telling what folks have configured in their tasks. Besides, isn't the server running all the time?
Posted: Tue Jan 22, 2008 2:33 pm
by Timoh
Yep... Have to agree with your reasoning.
I wired up some new inputs and the issue I was having was that they were not reporting on/off states correctly due to the threshold values. So I was flipping back and forth between cmax and HB and the inputs were changing and not being registered.
Then I said to myself "Hey Dummy.... Scott added the ability to change parameters from HB, so you don't need to do it in cmax!" And that's what I did.
If it was really an issue I just thought of a workaround in that at HB start, I could run a task that set my threshold parameters to a min value, then a max value, then back to where they should be. This would cause the Ocelot to report an on/off depending on the changed threshold value.
Tim