I’m on OH3.2.0.M4, on Windows 10 machine.
Using USB Legrand dongle, to pilot 4 roller shutter.
Everything worked fine for monthes, but since several days, after OH3 re-start, if all works well during a certain period of time (at least, I can open/close shutters using a switch item), it does not anymore the next morning.
I don’t know if linked (I can remember if this error was existing before), but I encounter the following error (warning only) at each OH3 server re-start:
2021-11-29 22:17:42.352 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.IllegalArgumentException: UID must have at least 4 segments.
at org.openhab.core.common.AbstractUID.<init>(AbstractUID.java:71) ~[?:?]
at org.openhab.core.common.AbstractUID.<init>(AbstractUID.java:49) ~[?:?]
at org.openhab.core.thing.UID.<init>(UID.java:48) ~[?:?]
at org.openhab.core.thing.ChannelUID.<init>(ChannelUID.java:51) ~[?:?]
at org.openhab.binding.openwebnet.internal.handler.OpenWebNetAutomationHandler.refreshDevice(OpenWebNetAutomationHandler.java:174) ~[?:?]
at org.openhab.binding.openwebnet.internal.handler.OpenWebNetBridgeHandler.refreshAllDevices(OpenWebNetBridgeHandler.java:400) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
I deleted & re-created bridge & things, no change.
What is strange is that it works for some minutes/hours right after re-start (even after this warning error), but no more the next morning. All automatic opening/closing fired by rules does not work as a consequence.
Some of my MH202 scenarios stop working after I reboot the RPi4. The “only if” conditions for the affected scenarios stop working and the scenarios do not run. The affected scenarios are CEN activated from another MH202 scenario. Like a subroutine. The “only if” conditions are a test for a boolean value and a test for switch on or off state. Toggling the switch does not help get the routine running again but if I remove the conditions on one of the affected scenarios then it runs but others do not.
What does the binding do at start up that could cause this and is the start up behaviour different from disable/enable (REST API) and stop/start ( Karaf console) ?
I have the RPi on a UPS, so reboots only happen when I command it. Even so, I need to rely on the MH202 scenarios running when I am away. If they stop I have to reboot the MH202 to get them working again. I do not think I can do that remotely and have to press the physical reset button on the MH202.
yes the log message is produced by the openwebnet binding. I lowered it to DEBUG level so it will not be printed anymore (change has been submitted to be included in OH3.2).
However I do not understand why this should be related to the stopping of writing logs. Is there any other message/error near the last written log message?
Hi Massi
Thanks for your interest.
I think I got some elements, it’s not due to the binding
Indeed, very suprisingly, after any update of the my.items file - Yes, I still manage some manually, to keep a backup -, when I save the file, then the controls of my roller shutters (inc. when triggerd from rules) do not work anymore until I re-start Openhab server.
The point is that it’s the only binding not working anymore after an update …
Need to further investigate.
(I’m on 3.2.0.M4).
at startup the binding needs to “re-synchronize” the state of all things (because they may have changed on the gateway while the binding was disconnected), so it will send a “state request” for all things/channels, except for CEN/CEN+ which are not state channels but trigger channels (they do not have a state)
OK thanks… So far it seems to be some (?) MH202 scenarios with switches in the only if conditions that fail to work after OH restart. I was wondering if I disable the thing before reboot and reenable it after reboot maybe the binding will not try to synchronise? Could it be that the sync request overwhelms the MH202? I tried toggling the effected switches used in the MH202 ‘only if’ scenario conditions but it did not appear to work. Only rebooting the MH202 gets it all working again.
I would consider moving some MH202 scenarios to OH but I need the dry contacts to work and some are mission critical and I still view OH as developmental and more likely to fail. The MH202 maybe be dumb but it works reliably works except now for the OH interference.
I never parametered any shutterRun parameter, so default value used “Auto”
Only “issue” is that when I save the .items file (when improving on my OH3 with new items), I need to re-start Openhab to have it working again. It’s not a big deal. When playing with my OH instance, I just need to not forget to re-start the server, otherwise, next morning, I need to use switches on the wall to open shutters, or I stay in the dark
I spotted a small bug that explains the log message you reported above, but even with this bug the control and trigger of the shutters via USB dongle should continue working, so I cannot reproduce your situation.
It would be useful if you set log level to DEBUG for openwebnet binding and openwebnet4j lib and then change the .items file and copy the entire openhab.log and send to me via Private Message.
This is because 99/4-zone Thermo is not fully supported yet.
See also the thread on Marketplace to provide feedback on 99/4-zone support.
It’s useful if you open a new issue in GitHub and there copy paste the own messages you see in the log (or in the BTicino official client) when the heating starts because temp goes below threshold.
Well you could have used: log:set WARN org.openhab.binding.openwebnet.internal.discovery
to set to warn just the discovery part.
In any case these discovery-related logs have been lowered to debug level in the upcoming 3.2 release (they were very very useful while debugging bticino gateway device discovery, which is stable and mature now).
I rebooted MH202 and then loaded the new 3.3.0.M1.beta1.bootsynch. I didn’t seem to need any dependencies. Not seen any issues so far but will know better tomorrow when a morning scenario with ‘only if’ conditions often fails to run after reloading the binding.
Note: I had a lot of problems when installing and uninstalling bindings , openwebnet and amazonechocontrol usually give me a headache. Sometimes all bindings then fail to reload. Repeated reboots seem to eventually fix the problem. This latest one casue no trouble at all.