So i’ve started using the “switch dashboard with item value” functionality of Habpanel and it’s very useful. Primarily I use it to override the panels on a specific event (eg, security camera motion) and select the camera view dashboard.
I have several tablets around the house running different panels, and for simplicity I trigger them all from the same item value, what would be most useful however is the ability to unset this item (NULL/UNDEF probably) and have habpanel revert to the previous dashboard
This would allow a user to clear a security alert on one panel, and have all the others revert to their original status untouched.
The autoswitch calls a $location.url. What I would do, instead of storing a dashboard id temporarily, is to simply go ‘back’
if (item.state == 'NULL') {
$window.history.back();
} else {
...
you would need to inject $window. The beauty of this is that, it will just go back to where it was. So if that panel was currently on an edit page, and entering stuff on an input box, it will go back to that edit page, with all the previously entered stuff restored.
…
and just for fun, what if I have a dashboard with id = ‘NULL’
@luckymallari I guess there’s two ways of handling this (as undef would have the same issue)
Either: Decide that having a dashboard called null/undef is silly and invalid (as you would generate persistence issues with this as well)
or
Have a secondary check which only returns down the history stack if the item.state doesn’t correlate to a valid dashboard (this would enable you to use “any” value to return, but could cause further issues if you changed a dashboard name / ended up with items/habpanel slightly out of sync)
I’d rather have HABPanel keep the item in sync with the current dashboard (i.e. updating the item’s state when the dashboard changes), which it does not do currently, this way you could implement any behavior you wish using associated items and rules on the server, something like this:
Group gCurrentDashboards
Group gPreviousDashboards
String Panel1_CurrentDashboard (gCurrentDashboards)
String Panel1_PreviousDashboard (gPreviousDashboards)
String Panel2_CurrentDashboard (gCurrentDashboards)
String Panel2_PreviousDashboard (gPreviousDashboards)
...
rule "store previous dashboard"
when
Panel1_CurrentDashboard changed or
Panel2_CurrentDashboard changed or
Panel3_CurrentDashboard changed or
(...)
then
val previousDashboardItem = gPreviousDashboards.members.findFirst[i| i.name == triggeringItem.name.split("_").get(0) + "_PreviousDashboard"]
previousDashbordItem.postUpdate(previousState)
end
rule "restore previous dashboards"
when
gCurrentDashboards received update "Restore"
then
gCurrentDashboards.members.forEach[item|
val previousDashboardItem = gPreviousDashboards.members.findFirst[i| i.name == item.name.split("_").get(0) + "_PreviousDashboard"]
item.sendCommand(previousDashboardItem.state.toString)
end
You could then send commands to the group to change all current dashboards at once or “Restore” to restore the previous ones.
if that’s the case, it would be better to have each Panel its own unique ID and saved onto localstorage, so that OH can send a command to each individual panel:
sendCommand(habPanelCommandItem, "{ to: 12345, command: ...}")
and Habpanel will handle command if to matches its id. Having no to is an implicit all
@ysc the principal of having it managed at the oh level is ok, however as soon as two panels are opened at once you would end up with massive item conflicts with each one trying to keep in sync, if you had two people at once this would cause bedlam. If not you would need to manage the panel config locally for each panel which makes adoption difficult
E.g.:
A panel config has multiple dashboards, one for each room in the house
A guest arrives in the house and installs the panel on their tablet. Without knowledge of the system this tablet either wouldn’t sync to the item commands or would try to copy the behaviour of other tablets. In the situation where you have multiple tablets (in different parts of the house) each tablet syncing becomes a pain as all tablets display where the last used tablet was, rather than where is useful for their area.
In my example above, the panel reporting back to the item would be unuseable, whereas the back functionality allows a basic restore function.
I guess you could support both in someway, but I certainly viewed this as more useful for broadcast items, not single tablet control