This object is in archive! 

[#EDX-895-20434]: Virtual device status and variable init to false/0 after a reboot/reset or cloud maintenance

Jerome shared this problem 5 years ago
Solved

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

Best Answer
photo

Yes, this is what I see too.

Comments (30)

photo
1

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.

photo
1

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 ;)

photo
1

+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

photo
1

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?

photo
1

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 ;)

photo
1

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!

photo
1

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

photo
1

This is great news!

photo
1

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?

photo
1

After a reboot, the problem still appears to be present :-(

photo
1

Great

HeroS wrote:

This is great news!
+1 ;)

photo
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?

photo
1

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

photo
1

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

photo
1

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 :-(

photo
2

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.

photo
1

Milan Gulis wrote:

Hello,


although saving virtual devices state to Zipabox physical memory sounds very simple and light it is most definitely not. If we would save those states to Zipabox memory, sooner or later it would happen that some user damges Zipabox memory simply by creating some rule with virtual devices which are constantly changing their state. We can't allow that kind of option to be even possible. This is the main reason why this implementation is could based for now.

Do you mean physically damage the Zipabox flash memory by writing it too many times?

photo
1

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

photo
1

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"?

photo
2

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.

photo
1

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!

photo
2

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).

photo
2

Hi all,


The issue should be fixed in the beta release. We apologise for any inconvenience caused.

photo
1

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:

photo
1

Yes, this is what I see too.

photo
1

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.

photo
1

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...

photo
1

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 :-(

photo
1

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.

photo
1

Perhaps it's just related to cloud maintenance nowdays. Maybe one could detect the status of the Zipato cloud service with some kind of IP check. Like ping or connect to some port in the could service. Then we would at least know when it's a problem :-)

photo