[#EDX-895-20434]: Virtual device status and variable init to false/0 after a reboot/reset or cloud maintenance
Ticket ID: EDX-895-20434
Bug open since september 2013 !
zipato support no longer responds
problem : after a reboot, a reset or an cloud maintenance, the Virtual devices status and the variables init to false/0 !
De : Zipato
Support
Sujet : [#EDX-895-20434]:
Virtual device status after a reboot/reset init to false
Hello Unfortunately , we still didn't implement solution for saving
state of a virtual devices so it is preserved through power failure or Zipabox
reset.to save a state of a virtual device, as simple as it sounds it still
requires some implementation in our could service which has to be done carefully
so we don't create additional bugs.I will have to ask you for a little
patience until we implement solution for this. I expect that we will have
implement this in next two weeks, but I can't promises anything for sure as
there are always some set back's that can occur. Kind
regardsMilanwww.zipato.com Ticket Details
Ticket ID: EDX-895-20434Department: GeneralType: FeatureStatus:
In ProgressPriority: High
The same problem 
Yes, this is what I see too.
Yes, this is what I see too.
This is not a bug, but feature. Ordinary, variables are not being fixed or the name should be different. As for the virtual switches, they will have an option to save a status in memory, but this feature will be added in one of the following versions.
This is not a bug, but feature. Ordinary, variables are not being fixed or the name should be different. As for the virtual switches, they will have an option to save a status in memory, but this feature will be added in one of the following versions.
I am using variables for some automated actions like opening/closing blinds, switching lights automatically.
I created a virtual switch to enable/disable automated tasks, so whenever I don't want these actions to be automatically done, I switch off that virtual switch.Problem is that if zipabox is rebooted, it first will have to switch off/on the virtual switch. Otherwise the tasks linked to that variable or virtual switch won't execute as wanted.
Do you plan to allow system to keep variable/virtual switch states after reboot soon? It could be useful ;)
I am using variables for some automated actions like opening/closing blinds, switching lights automatically.
I created a virtual switch to enable/disable automated tasks, so whenever I don't want these actions to be automatically done, I switch off that virtual switch.Problem is that if zipabox is rebooted, it first will have to switch off/on the virtual switch. Otherwise the tasks linked to that variable or virtual switch won't execute as wanted.
Do you plan to allow system to keep variable/virtual switch states after reboot soon? It could be useful ;)
+1
once again, all my virtual devices were reseted and my shutters were not open this morning.
:-(
It's not a feature request but a bug because the graphical state is not reseted to off/false after an cloud maintenance.
Please, correct this problem as soon as possible now
+1
once again, all my virtual devices were reseted and my shutters were not open this morning.
:-(
It's not a feature request but a bug because the graphical state is not reseted to off/false after an cloud maintenance.
Please, correct this problem as soon as possible now
same request :
http://community.zipato.com/responses/variable-values-after-power-failure-and-restart
same request :
http://community.zipato.com/responses/variable-values-after-power-failure-and-restart
I have some long wait statements in some of my rules that also get interrupted by simultaneously restarts of the box. Eg I'd like a lamp to be turned on 1h prior to sundown. So upon yesterdays sundown I wait 23h before action on light.
Or other solution avalible?
I have some long wait statements in some of my rules that also get interrupted by simultaneously restarts of the box. Eg I'd like a lamp to be turned on 1h prior to sundown. So upon yesterdays sundown I wait 23h before action on light.
Or other solution avalible?
thomasfr, you can reverse your virtual OnOff switch :
When ON -> Manual ; When OFF -> AutoThen the system will be in AUTO mode by default, if your zipabox reboots
If you have not a lot of virtual devices, you can implement a Virtual switch that should be always ON to dectect power failure/reboot.If failure is detected you can call an URL on a local server to push back privious data in the zipabox. Crappy, but works ;)
thomasfr, you can reverse your virtual OnOff switch :
When ON -> Manual ; When OFF -> AutoThen the system will be in AUTO mode by default, if your zipabox reboots
If you have not a lot of virtual devices, you can implement a Virtual switch that should be always ON to dectect power failure/reboot.If failure is detected you can call an URL on a local server to push back privious data in the zipabox. Crappy, but works ;)
Great!
These are 2 pretty cool tips!!
Thanks for sharing ;)
Concerning the fact of calling an url from a local server, are you using a script?
Can you share it?
Thanks again for your help!
Great!
These are 2 pretty cool tips!!
Thanks for sharing ;)
Concerning the fact of calling an url from a local server, are you using a script?
Can you share it?
Thanks again for your help!
Hello Jerome
This issue is
in process of resolving. We did implement additional space in our database for
saving those state so they would be consistent during Zipabox reboot.
Will
let you know when we manage to complete and test this
implementation.
Kind regards
Milan
http://www.zipato.com
Ticket Details
Ticket ID: EDX-895-20434
Department: General
Type: Feature
Status:
In Progress
Priority: Normal
Hello Jerome
This issue is
in process of resolving. We did implement additional space in our database for
saving those state so they would be consistent during Zipabox reboot.
Will
let you know when we manage to complete and test this
implementation.
Kind regards
Milan
http://www.zipato.com
Ticket Details
Ticket ID: EDX-895-20434
Department: General
Type: Feature
Status:
In Progress
Priority: Normal
This is great news!
This is great news!
Hello Jerome
This issue has been resolved. When you Zipabox is reboot ( power failure or reset button ) it will load all virtual devices state from our server, which means that virtual devices state is now preserved through Zipabox reboot.
Kind regards
Milan
www.zipato.com
Ticket Details
Ticket ID: EDX-895-20434
Department: General
Type: Feature
Status: Closed
Priority: Normal
Support Center: http://support.zipato.com/index.php?
Hello Jerome
This issue has been resolved. When you Zipabox is reboot ( power failure or reset button ) it will load all virtual devices state from our server, which means that virtual devices state is now preserved through Zipabox reboot.
Kind regards
Milan
www.zipato.com
Ticket Details
Ticket ID: EDX-895-20434
Department: General
Type: Feature
Status: Closed
Priority: Normal
Support Center: http://support.zipato.com/index.php?
After a reboot, the problem still appears to be present :-(
After a reboot, the problem still appears to be present :-(
Great
+1 ;)Great
+1 ;)the zipabox save the value on-off but not true-false while in the log displayed values are true/false.
is not clear. Can you fix this?
the zipabox save the value on-off but not true-false while in the log displayed values are true/false.
is not clear. Can you fix this?
after a reboot, the virtual switch no longer work
The rules do not seem to be able to check or compare the state
of virtual switch.
If I click on buton On, after 10s it switches off automatically and no
event appears in the event log
after a reboot, the virtual switch no longer work
The rules do not seem to be able to check or compare the state
of virtual switch.
If I click on buton On, after 10s it switches off automatically and no
event appears in the event log
Hi Jerome
Issue is no longer present. I tested this on my Zipabox. If for your virtual device state can't be checked then please re-add your virtual device and try again. Also, take not that this will not work if our server is down or your Zipabox can't reach it, as those states are being saved and loaded from our cloud.
Kind
regards
Milan
Hi Jerome
Issue is no longer present. I tested this on my Zipabox. If for your virtual device state can't be checked then please re-add your virtual device and try again. Also, take not that this will not work if our server is down or your Zipabox can't reach it, as those states are being saved and loaded from our cloud.
Kind
regards
Milan
someone else can test it ?
for me, it still does not work after a reboot.
I do not understand why you make the virtual devices cloud depending :-(
someone else can test it ?
for me, it still does not work after a reboot.
I do not understand why you make the virtual devices cloud depending :-(
Seems to work here... After reboot all the devices starts to appear in the event log again. The only "problem" as I see is that rules will be triggered again.
Eg if I turn on the light upon opening the door upon arrival to home. If I then is home and the box reboot it will happen again since reload of devices will trigger the same.
Seems to work here... After reboot all the devices starts to appear in the event log again. The only "problem" as I see is that rules will be triggered again.
Eg if I turn on the light upon opening the door upon arrival to home. If I then is home and the box reboot it will happen again since reload of devices will trigger the same.
State are saved on zips server, but watch happen if the box can access to your server. In my house, after a power off, my provider router need 2 to 5 min to be synchro ...
And during my holiday i switch off the router
State are saved on zips server, but watch happen if the box can access to your server. In my house, after a power off, my provider router need 2 to 5 min to be synchro ...
And during my holiday i switch off the router
I have a rule that sets a virtual switch to "on" just after midnight on weekdays. Several rules execute later in the day and only work if the switch is "on". I notice that the rules work seemingly at random. Some days they don't run. But the switch always appears to be in the correct state. I created a test rule and it failed work - it was seeing the variable as "off" even though it was "on". Then I toggled the virtual switch to "off", and back to "on" in the Device Manager, and reran the rule. Now it worked.
This means:
1) Sometimes the Device Manager shows a virtual switch to be "on" when it isn't.
2) Something happens during the night to cause this discrepancy, but only on some days.
Could it be that if the box disconnects during the night, it loses the switch states, and then fails to reestablish them on reconnecting? So you continue to see the original correct switch states in the web application (because they're correct in the cloud) but on the box the states have actually been reset to "off"?
I have a rule that sets a virtual switch to "on" just after midnight on weekdays. Several rules execute later in the day and only work if the switch is "on". I notice that the rules work seemingly at random. Some days they don't run. But the switch always appears to be in the correct state. I created a test rule and it failed work - it was seeing the variable as "off" even though it was "on". Then I toggled the virtual switch to "off", and back to "on" in the Device Manager, and reran the rule. Now it worked.
This means:
1) Sometimes the Device Manager shows a virtual switch to be "on" when it isn't.
2) Something happens during the night to cause this discrepancy, but only on some days.
Could it be that if the box disconnects during the night, it loses the switch states, and then fails to reestablish them on reconnecting? So you continue to see the original correct switch states in the web application (because they're correct in the cloud) but on the box the states have actually been reset to "off"?
I am experiencing the same issue. I have virtual switches used to enable/disable rules, or make some rules silent/loud (using Zipato indoor siren) and for some reason these rules don't behave according to the virtual switch status and I have to force switch update to go back on track. This subject brings me the explanation, yet it is a strong limitation and it is disapointing to find out it has been raised a long time ago and not fixed.
I am experiencing the same issue. I have virtual switches used to enable/disable rules, or make some rules silent/loud (using Zipato indoor siren) and for some reason these rules don't behave according to the virtual switch status and I have to force switch update to go back on track. This subject brings me the explanation, yet it is a strong limitation and it is disapointing to find out it has been raised a long time ago and not fixed.
Yes, I think this is also the cause of most if not all my outstanding reliability problems with the Zipabox.
I have several possible solutions:
- Run the rules that set the virtual switches every 15 minutes to reset the values (this is only possible if you can calculate their values from basic information like date, temperature, day of the week, etc. If you're using them to store some other state or event then this isn't possible).
- Trigger a "subroutine" rule from the rule where the virtual switch is used to calculate the switch states (again, the same limitation). My tests at the moment suggest that this doesn't work because the rule that "calls/triggers" the second rule doesn't receive the updated switch states, even if you use "Refresh All". I also tried using variables, but the effect is the same. The rule that sets them needs to run *before* the rule that uses them, rather than being triggered by it.
- Use variables instead of virtual switches. They don't seem to get out of sync in the way that virtual switches do. As I understand it, if you reboot, variables lose their values (virtual switches supposedly don't). But whereas virtual switches seem to get reset in the Zipabox (but not in the cloud) when the Zipabox disconnects for any reason, this doesn't seem to happen to variables!
Yes, I think this is also the cause of most if not all my outstanding reliability problems with the Zipabox.
I have several possible solutions:
- Run the rules that set the virtual switches every 15 minutes to reset the values (this is only possible if you can calculate their values from basic information like date, temperature, day of the week, etc. If you're using them to store some other state or event then this isn't possible).
- Trigger a "subroutine" rule from the rule where the virtual switch is used to calculate the switch states (again, the same limitation). My tests at the moment suggest that this doesn't work because the rule that "calls/triggers" the second rule doesn't receive the updated switch states, even if you use "Refresh All". I also tried using variables, but the effect is the same. The rule that sets them needs to run *before* the rule that uses them, rather than being triggered by it.
- Use variables instead of virtual switches. They don't seem to get out of sync in the way that virtual switches do. As I understand it, if you reboot, variables lose their values (virtual switches supposedly don't). But whereas virtual switches seem to get reset in the Zipabox (but not in the cloud) when the Zipabox disconnects for any reason, this doesn't seem to happen to variables!
I've just done a test which proves that, when a switch is not behaving as it should, its state is out of synch.
My "working day" switch appeared to be on in the Device Manager. But the conditions which tested for the "on" state evaluated to false. So I tried running a rule which toggled the "working day" switch twice. Toggling the switch twice will not change its state, but will force a resynch of its state between the box and the cloud. Since the rule is executing on the box, the starting state will be the box's state, not the one you see in Device Manager.
As expected, after toggling the switch twice, it changed from "on" to "off" in Device Manager.
So Device Manager is lying about the state. It's not synched to the box (or, rather, the box has not been resynched to the cloud state after a disconnection).
I've just done a test which proves that, when a switch is not behaving as it should, its state is out of synch.
My "working day" switch appeared to be on in the Device Manager. But the conditions which tested for the "on" state evaluated to false. So I tried running a rule which toggled the "working day" switch twice. Toggling the switch twice will not change its state, but will force a resynch of its state between the box and the cloud. Since the rule is executing on the box, the starting state will be the box's state, not the one you see in Device Manager.
As expected, after toggling the switch twice, it changed from "on" to "off" in Device Manager.
So Device Manager is lying about the state. It's not synched to the box (or, rather, the box has not been resynched to the cloud state after a disconnection).
Hi all,
The issue should be fixed in the beta release. We apologise for any inconvenience caused.
Hi all,
The issue should be fixed in the beta release. We apologise for any inconvenience caused.
After a restart the box remembers neither yes or no or any values. It contains a request to the server about help to remember. And if the communication is down, when the box restarts, this is what to bee left in the variables in the box:
After a restart the box remembers neither yes or no or any values. It contains a request to the server about help to remember. And if the communication is down, when the box restarts, this is what to bee left in the variables in the box:
Yes, this is what I see too.
Yes, this is what I see too.
I am now pretty sure that this has NOT been fixed by 0.9.999.8w.
I created a switch, set it to "on" and created a rule to test its state periodically. This morning it flipped to "off" by itself.
I'll do some more tests.
I am now pretty sure that this has NOT been fixed by 0.9.999.8w.
I created a switch, set it to "on" and created a rule to test its state periodically. This morning it flipped to "off" by itself.
I'll do some more tests.
Hey, it is not a big problem...
Zipabox is still in beta (v0.9), they'll correct it for v1.0 (if it comes out one day)
HAHaha...
Hey, it is not a big problem...
Zipabox is still in beta (v0.9), they'll correct it for v1.0 (if it comes out one day)
HAHaha...
I just want to confirm that I have the same issue. This is a big problem because I have a lot of rules (60+) and a lot of switches (20+). Things go completely haywire when the switches don't work :-(
I just want to confirm that I have the same issue. This is a big problem because I have a lot of rules (60+) and a lot of switches (20+). Things go completely haywire when the switches don't work :-(
This used to work but now it doesn't anymore... Has something changed with this again?
I updated to latest beta (1.1.23) and but didn't help.
This used to work but now it doesn't anymore... Has something changed with this again?
I updated to latest beta (1.1.23) and but didn't help.
Replies have been locked on this page!