[Solved] Difference between Web UI and actual RF states.
5 July, 2010 - 23:42
Following a reboot, my system sometime seems to reports RF 1 as being off, even after a GoogleCal 'on' command and the module actually being on(i.e. tested by watching TV).
Looking at XFX, I can see the GoogleCal messages but in RF 1, the state is OFF and no changes taking place.
Just a glitch?
I have screen dumps, just not sure where to send them...
Cheers
Gary
6 July, 2010 - 14:25
#3
The Web service runs
The Web service runs disconnected from the RF remotes. If a Google Calendar event fires (ON), the web page, being shown in the browser, will continue to report (OFF) until you refresh the page. Once refresh it will report the correct state. Why? Because the web-server is stateless. Once it queries the XAP-LIVEBOX daemon to get the current values to make a HTML page which is sent to your browser. That's it's job done. It goes back to sleep waiting for the next request. If the state in the meantime changes due to an XAP event the web-server just doesn't care until is asked to care by a Browser refresh.
Personally I'm not a big fan of web-browsers for control purposes for this exact reason, but hey if you don't have a web interface nobody wants to use your toys. :)
As Derek pointed out, whenever the HAH does a reboot all the learned state will be lost. This means that if an RF socket was ON and the HAH knew it. A reboot will make it forget. I guess I could persist the ON, but what happens if you unplug your RF socket in the meantime so its now OFF. The reboot will turn it back ON again and your right back where you started. You just can't win at that game.
This is only solvable if the RF sockets had a full Tx/Rx RF pair so you could poll them and ask them what statethey are in. That said I don't know of any domestic RF units that do this.
We do the best with what we have.
Brett
I suspect that the UI being out of sync with the current state of the RF device is due to the nature of the RF devices themselves. Unlike things like the temperature sensors and the input lines, the HAH cannot query the current state of the RF sockets. So, if somebody turns the socket off manually, the HAH doesn't know about this. Further, if for some reason, the socket doesn't receive the RF signal from the HAH, the HAH cannot know this. RF is very much 'fire and forget'.
That said, in practice, the operation of the RF sockets is very reliable.
I'm betting that the HAH firmware, on power up/reset, sets its RF state tracker to 'off'. Brett would be able to confirm this.
Suppose an option could be implemented to send out RF commands at power on time to force the RF devices to a given state. However, this would take some effort to build and test.
That said, if after a reboot, you send a valid RF 'on' command and the UI doesn't track this, it's most likely a bug.