This object is in archive!
Rules often stop working altogether following modifications, until a reboot
Known
I noticed early on with the Zipabox that, after modifying rules or creating new ones, synchronising was not enough. I needed to reboot, otherwise *all rules* would stop working. This is still the case.
I think maybe only certain types of change cause this to happen. Anyone else seen this?
The same problem 
No connection
Real-time notifications may not work
I should maybe qualify this a bit: rules that only affect virtual devices do seem to carry on working. But rules no longer seem able to interact with physical devices until the reboot.
I'll do some more tests.
I should maybe qualify this a bit: rules that only affect virtual devices do seem to carry on working. But rules no longer seem able to interact with physical devices until the reboot.
I'll do some more tests.
Do that, I would like to know as well.
Do that, I would like to know as well.
According to my experiences it depends on what's trigging those rules.
If it is changed rules and they are trigged by the scheduler they seems to be used after the next trigs.
If it is new rules and with a new scheduler they acts the first time. But in a way this is logical.
According to my experiences it depends on what's trigging those rules.
If it is changed rules and they are trigged by the scheduler they seems to be used after the next trigs.
If it is new rules and with a new scheduler they acts the first time. But in a way this is logical.
If you are following this thread https://community.zipato.com/topic/zipabox-restarts-without-apparent Zipato has, at last, becomes aware of the problems with the scheduler.
They have identified the scheduler as the source of all my spontaneous restarts of the box and are rewriting parts of the scheduler puzzle now. I have just got that message on a ticket. Maybe it will have some impact on this case too?
If you are following this thread https://community.zipato.com/topic/zipabox-restarts-without-apparent Zipato has, at last, becomes aware of the problems with the scheduler.
They have identified the scheduler as the source of all my spontaneous restarts of the box and are rewriting parts of the scheduler puzzle now. I have just got that message on a ticket. Maybe it will have some impact on this case too?
Maybe. I'm not sure what's going on. I'm logging all the changes I make and I'm just synchronising, not rebooting. So far, the problem hasn't recurred. So it must be just due to certain sorts of changes. I'll post when I learn more.
Maybe. I'm not sure what's going on. I'm logging all the changes I make and I'm just synchronising, not rebooting. So far, the problem hasn't recurred. So it must be just due to certain sorts of changes. I'll post when I learn more.
What I do know is that the scheduler doesn't work reliably. For example, I recently created a test rule to run every hour and according to the log it generally runs every 2 hours.
I've set up a Master Scheduler rule to run the rules that I need executed every 10, 15, 20 or 30 minutes (it runs every minute) and that works just fine.
What I do know is that the scheduler doesn't work reliably. For example, I recently created a test rule to run every hour and according to the log it generally runs every 2 hours.
I've set up a Master Scheduler rule to run the rules that I need executed every 10, 15, 20 or 30 minutes (it runs every minute) and that works just fine.
I have been noting down my rule modifications for a couple of days, synching but never rebooting. And this morning I finally got a failure: a couple of my morning rules failed to run, the ones that open blinds and turn the Sonos/amp on (although, oddly, another rule did work). I can't see any obvious pattern. Last night the blinds closed as normal, and no modifications were made afterwards.
The only theory I can think of is that it has some connection with the box going offline during the night. The hypothesis would be:
1. If you change the rules, you synch but don't reboot and the box goes offline, then (some) rules stop working.
2. If you change the rules, you synch AND reboot and the box goes offline, then rules continue to work.
Not sure how to test this.
I have been noting down my rule modifications for a couple of days, synching but never rebooting. And this morning I finally got a failure: a couple of my morning rules failed to run, the ones that open blinds and turn the Sonos/amp on (although, oddly, another rule did work). I can't see any obvious pattern. Last night the blinds closed as normal, and no modifications were made afterwards.
The only theory I can think of is that it has some connection with the box going offline during the night. The hypothesis would be:
1. If you change the rules, you synch but don't reboot and the box goes offline, then (some) rules stop working.
2. If you change the rules, you synch AND reboot and the box goes offline, then rules continue to work.
Not sure how to test this.
Nearly everything we are doing are qualified guesses. The tools are nearly nonexistent. But I'm more and more afraid that the box is far too dependent on the net. How do you otherwise explains this varying intervals between the restarts in my box. It's the same software in the box but the time between crashes varies very much.
Nearly everything we are doing are qualified guesses. The tools are nearly nonexistent. But I'm more and more afraid that the box is far too dependent on the net. How do you otherwise explains this varying intervals between the restarts in my box. It's the same software in the box but the time between crashes varies very much.
Good point. Still, it's strange that you have so many restarts. I can say that my box has almost never rebooted by itself.
Good point. Still, it's strange that you have so many restarts. I can say that my box has almost never rebooted by itself.
I have 80 scheduler on time. 56 of them ends up in random waits between 1 to 30 minutes, or more, before action to avoid the impression of an empty house. 21 of them runs every 3d minute. 2 runs every minute. Maybe that's to much for Zipato? But I haven't figured out how to avoid this and still reach my goal.
I have 80 scheduler on time. 56 of them ends up in random waits between 1 to 30 minutes, or more, before action to avoid the impression of an empty house. 21 of them runs every 3d minute. 2 runs every minute. Maybe that's to much for Zipato? But I haven't figured out how to avoid this and still reach my goal.
Most of my problems should be simple to solve if the system have had memory variables with visible contents. But variables in memory is a blind point. I haven't the slightest idea of the content of a variable. Therefore I have to use a meter instead. And every time I update a meter it should be updated by the net to the server. It will be a hell of traffic.
The other problem with variables is that I can't remove them. And to develop a complex system without the possibility to correct mistakes is not realistic.
Most of my problems should be simple to solve if the system have had memory variables with visible contents. But variables in memory is a blind point. I haven't the slightest idea of the content of a variable. Therefore I have to use a meter instead. And every time I update a meter it should be updated by the net to the server. It will be a hell of traffic.
The other problem with variables is that I can't remove them. And to develop a complex system without the possibility to correct mistakes is not realistic.
Replies have been locked on this page!