After the first hooray with a working system there’s now “deep despair”.
I’ve set up a Pi based home control (to be more exact 4), the PIs are running isolated (no internet) and have no RTC. Now after testing the system in the field and making some changes with the item definition the effect is that after 10 seconds all active lights (GPIOs) go down.
After some investigation i found out, that this is because of the “hot deploy” feature. So i thought - simply turn it off, i dont need this anyway.
the system no longer reads the definitions at all, at least i can not access the sitemaps. Most probably this is a timing problem…
So i had to revert to “file observation mode” (while still thinking this is a bug) and to dig in still deeper, why OH is re-reading the definition file at all. The reason i found is twofold: on on hand, the files that come from my development notebook via ssh have a correct timestamp. The Pi has “no time at all”. So, probability is high that the files are found as “new”. Now the FolderObserver initiates a reload - but here we have another bug/feature: after reloading FileObserver does not remember the timestamp of the file access, but the current timestamp!! If the two times of Pi and notebook differ enough this leads to a nearly endless reloading, shutting down the lights every now and then.
All in all - there’s no option to live with in this “island configuration”. I can not switch off reloading (because the whole system stops working) and i can not switch on reloading (because the system does not reliably detect changes).
If the time on your Pi is really off when compared to your development machine then it seems like a simple fix would be to make the times on the two machines as close as possible using the date command or setting up a time server your Pis can get to. Even if you put a time server on your dev machine which isn’t connected to the Pis all the time they can still sync their clocks periodically when you connect to the dev machine to update the configs. In my experience they don’t fall out of sync all that fast so even once a month or more infrequently could keep them in sync enough to work.
Given Time based triggers in openHAB I would think you would want the time to be pretty close to accurate anyway.
The file polling does so based on the current machine clock and the timestamp. So as long as the timestamp on your config file is newer than the last time it polled for files it will load it, as you have seen. Once the time on the Pi catches up to the timestamp of the file the reloading should stop. So you either need to set the clock on the Pi so it matches the dev machine’s or you need to set the timestamp on the config files to match the Pi’s clock using the touch command.
the touch command may help here to get the system up immediately.
But the 4 machines will run unattended in 4 foreign appartments, so there should be no regular maintenance necessary. I am not sure what time the pi will have when it has an outage and wakes up. If this time is by hazard far from the file timestamps -> desaster.
The best solution i see is a change in the FolderObserver. If he remembers not the time he has last seen a change, but the timestamp of the file change, in every case only a single reload will be triggered. Is there any chance to get such a fix?
P.S. I think i will be adding the touch command simply to the startup script - this will catch the situations when the Pi starts with unknown time. Thanks for adding this pointer.
I really think adding a RTC, but still need some short time measure. Is this the gadget you have addedd - there are a lot of components around and i’m a little unsure.
On the long term, internet connectivity for administration will be added anyway, so i will get external time.
I’ve used an RTC with a Pi for experimentation, but not for openHAB purposes. There are numerous similar devices and boards that can be used with the Pi. The RTC I’ve used is…
If I were using for the purpose you describe I’d probably look for a board that can plugged directly onto the Pi GPIO pins. Something like…
The RTC devices are relatively inexpensive ($5-10) so it’s not risky in that sense. However, configuring the Pi to use the device correctly can be a bit complex.
Updates to the core of OH 1.x have been frozen so probably not, though that is a question for @kai. A very simple change like this might be considered but I don’t want to speak for the project leadership.
Have you seen this in practice? My Pis routinely go down and I’ve never had one come up with its clock that far off. However, I also use a timeserver so perhaps I’ve simply not noticed. From your initial description it sounded like it was mainly a problem when you uploaded changes to the configs.
I usually leave the decision to @teichsta whether a change is important enough to do it still in the 1.x runtime. If it is either critical or at least has very little risk of side-effects, such a fix should be fine - as long as it is checked that the code is kept in sync with Eclipse SmartHome.
Have you seen this in practice? My Pis routinely go down and I’ve never had one come up with its clock that far off. However, I also use a timeserver so perhaps I’ve simply not noticed. From your initial description it sounded like it was mainly a problem when you uploaded changes to the configs.
No, i just don’t know what is the Pi’s default behavior and if it is deterministic at all. The problem occured when i worked the first time out of my lab (where i have internet connectivity) onsite.
Touching the files on startup is a valid workaround,
Maybe one should keep this in mind for the 2.0 line of development (@kai)
defining a reliable startup order
remember last file access time, not last lookup time
