I have an ACT wall switch which Vera sees as a scene controller.
Trouble is that whenever I operate it I see no change in its Status (by viewing the advanced tab and scrolling down to the “Status” variable). However, it was clear that something was happening judging by what was going on in my Lua code.
After much experimentation I discovered that the “Status” variable was in fact being modified correctly but this was not being reported to the UI. I discovered this when I reloaded the UI and got the correct value displayed. Trouble is that you have reload it every time. Plenty of other variables display without the need for a reload (but may need a “poll” first) so why this one?
This is seriously annoying when I am trying to debug my code and has caused me a lot of wasted time up several blind alleys.
The Advanced Tab doesn’t update in real time. But if you depart the tab, say, by going to a different tab, and then return, the values are refreshed to their current values. If you’re seeing different behaviour for the Status variable, it’s a first.
If you follow the Luup log while operating the switch, is there evidence that the Status variable is changing?
Switching tabs and returning to Advanced makes no difference even if I do this a number times and allow plenty of time to elapse.
The value of “Status” has clearly changed (off to on in this case). I can see the new value “1” by running a scene with a variable_get and displaying it in the variablecontainer device. The “Status” field in the Advanced tab still shows “0”. After a reload the correct value is displayed.
I will run some more tests when I have some time available but the results so far look pretty compelling.
By reload, are you referring to the refresh button of the browser or the reload button in Vera’s web interface? If you try and refresh the page via the refresh button of the browser, does the values change?
I was using the Vera reload button but have now tried refreshing from the browser. It gives the same result i.e. the correct value is displayed. I am using Chrome on a Macbook Pro. Thought it might be a problem with Chrome so tried Safari with the same result.
Just to be sure of my testing regime.
After operating the switch and manually running a test scene I have the new correct value displayed in variable container.
I then check this out in the advanced tab for the switch device which is still showing the previous value.
I reload the browser and the correct value is displayed.
It might be that the web interface doesn’t bother updating the UI for variables that aren’t in a matching service. This is a grey area and I never bothered to investigate closely, but it goes something like this:
There are two places where variables are kept in Vera: the LuaUPnP engine and the JavaScript environment on the browser. If you update an arbitrary variable on the browser then it doesn’t necessarily update LuaUPnP immediately. That’s why the SAVE button exists, to flush that cache back to the engine. Perhaps in the other direction variables that change directly in LuaUPnP that aren’t marked as state variables don’t filter through to JavaScript.
Take a look at your device’s (one or more) S_*.xml files and look for the variable with matching Service Id and name. Is it to be found?
The Web Interface does a soft reset when it detects that Vera has restarted. This will update the variables in the Web Browser. Refreshing the browser loads the data from scratch into the Web browser. Both will make the new data available in the Advanced tab.
Plugins that have a JavaScript component that operate in the context of the Web browser have two choices when interacting with data. They can choose to operate with the Cached data that the web browser has loaded or they can do their own remote calls to get/set the persistent values in Vera.
The latter is more complex. Saving all the changes in the browser allows all the changes to be made in a single coherent transaction (The Save button). This makes development of plugins in a dynamic event driven environment like Home Automation to have a lot less weird boundary conditions to deal with.
Thanks all for your feedback. I think I understand - sort of.
The web interface is a representation of what is going on in the LuaUpnp engine and the variable values therein have to be repeated in the web interface by some discrete action. Makes sense to me - up to a point at least.
However, as far as I can see, the status of my switch will only be displayed in the web interface advanced tab as a result of a Vera reload or a web refresh both of which are exceptional actions. When will this variable be updated in the web interface otherwise - preferable at some point close to real time?
Secondly, why does the status of my appliance modules show up in their web interface containers immediately they are changed as is also the case with tripping my PIRs and changes in my temperature sensors? This is a noticeably contrasting behaviour and one that makes more sense. While we’re on the subject, I have never understood why the switch’s status does not appear in its container as with other device types.
Now I have a better understanding of what is (or should I say - is not) happening I have a work around by issuing a variable_get every time the scene triggers and displaying the status in a variable container field but it would be much simpler if the change of status simply posted in the container in the web interface as it happened. The techy reasons as to why this may not be possible are over my head but I think its still worth a plug with MCV. What do you think?
Did take a look at the S_*.xml files for this device. The “Status” state variable is not declared in any of them.
However (and I hope I am not teaching grandmother to suck eggs here) I also read that, a state variable may appear in the device which has not been explicitly declared in any of the associated S_*.xml files (as can be seen in the advanced tab in this case) it can be accessed using the matching service for that variable whether listed as a service or not and it definitely seems to work (in this case SwitchPower). Begs the question though why we have to declare the services in the first place.
That said my luup logic requires that the switch is sometimes set from the UI (rather than the physical switch) and then its state is read. If I have understood correctly, the switching instruction (call_action) will run asynchronously and the switch’s state may not have changed before it is tested giving me variable results. I have overcome this by forcing a value in the sl_SceneActivated variable and testing that thus allowing the switch state change to catch up in its own time.
What started out as me blaming the failure of the UI to reflect the real time position is solved with this work around but it would still be nice to be able to trust the UI to show the real time position.
terencec, here’s my thought process: the JavaScript UI for Vera learns the list of all the “interesting” variables that belong to a device by scanning the service files that the device points to. It may even filter them down to the ones that have a “sendEvent” attribute of yes. By not having the Status variable listed in a service, the JavaScript is using a cached value on the assumption that since no service mentions it, it won’t change.
I can’t prove that this is how the Vera JavaScript is written, but it’s consistent with observations. Indeed, it’s equally consistent that it’s the LuaUPnP executable that is choosing the list of interesting variables to push up to the JavaScript from those same service files.
You can test this by adding Status to the right service file, and seeing if the variable’s changes are reflected more quickly in the UI. My prediction is that they will.
The deeper answer to why you write service files at all is because they are part of the UPnP spec, and MiOS tries to adhere to select bits of the UPnP spec, this presumably being one of them.
I do not believe the JavaScript classes (Web Interface) look at the uPNP Service Definition Files at all.
When it reloads the web browser it makes a cache of ALL service variables for all devices in Vera. You can see these variables in detail by looking at the result of the “User_Data2” request.
This data is used by everything that is not on the “Dashboard”. (i.e. Scene Editor, Advanced Tab, …)
The Control Tab and the device display on the dashboard are handled differently. These controls when displayed cause an event mechanism to maintain the dynamic status of the state variables that drive them … (i.e. in the Countdown Timer plugin, the time remaining).
These state variables are maintained in a different storage than the state variables previously discussed.
In JavaScript the different (Static, vs Dynamic) values are accessed from the functions: Static:
get_device_state(deviceID, Svs, Variable);
set_device_state(deviceID, Svs, Variable, NewVal); Dynamic:
get_device_state(deviceID, Svs, Variable, 1);
set_device_state(deviceID, Svs, Variable, NewVal, 1);
When the Dynamic state is changed it does NOT update the static state.
When you call the Static set_device_state … it causes the SAVE button to be highlighted.
This does NOT happen when you call the Dynamic set_device_state.
I do not know the mechanism for what get’s redisplayed when the dynamic data changes.
I do not believe it is a side effect of the dynamic set_device_state function. The web UI might just repaint all DashBoard and Control tabs when Vera sends (Actually JavaScipt Polls) updates to the Web for the variables it is dynamically watching. The overhead of maintaining the dynamic data and possible in-coherent state of seeing the first few changes before the last set is why these are maintained separately.