Hi Mark, thanks for your suggestion.
Probably that’s a way to do it but, after looking at the logs I was thinking that I don’t need to detect the scenario execution adding something. The proper command is already sent on the Bus from the scenario itselft:
General lights off : *1*0*0##
I will make some testing but, I’ll try to create a virtual light switch for where=“0” that like yours doesn’t have a openhab state but should map exatcly the openwebnet command for General lights ON/OFF.
What would you like the virtual light switch to trigger in openHAB?
You can create a virtual light switch with WHERE=0 for general off and it will work correctly as long as you alternate on and off in BTicino. However, if you press off twice in a row in BTicino, then there is no way to detect the second off in openHAB. The switch will not change its state and even “was updated” as rule trigger does not fire.
I logged this already as an issue:
Not sure if that is acceptable for your use case. In my case it is not and I replaced the general off command with a CEN message:
At the start of a scenario using virtual switches it starts by sending an ON to the virtual switch and at the end of the scenario it sends an OFF. So they are always OFF and openHAB only responds to the change to ON. I don’t have issue with then getting out of sync.
OK, I understand, then your use case is different. I was looking at using the virtual switches to be controlled by physical BTicino switches. For your use case, what is the advantage of using a virtual switch compared to a CEN message?
The thing/item WHERE 0 works perfectly on the Bticino side when activated by a toggle switch in Openhab: all lights turn on or off. The status of all lights is not updated in Openhab, but this is where I wanted to add a rule to reconcile.
As you reported the problem is related to the fact that my physical switch always activates an OFF and if the openhab item has received the first OFF, it no longer trigger the state change for subsequent OFF. I have tried using autoupdate false, expire=“1s,NULL”, changing the state of the item to UNDEF or NULL via a rule, but so far I have had no success
Intrusion detected → Zone X alarm changed to INTRUSION in Openhab
Alarm disarmed (intrusion led on inserter 4607/4 track the intrusion and is on)
Alarm re-armed (intrusion led reset on inserter 4607/4 and turn off).
In openhab the zone alarm status once set to INTRUSION, remain to INTRUSION. Restarting openhab reset the value to NULL.
I suppose that on step 4 the zones armed should reset their zone alarm status (if a zone detect something wrong the alarm won’t arm) but, I haven’t set the log to debug and gathered bus messages.
Anyone has any clue on this?
I’ll make another try collecting logs asap.
This part of alarm support was not tested unfortunately: the testers I recruited for the beta version where not able to test it before the final submission for OH 3.4.
So if you can repeat the sequence you described but with log level to DEBUG and send me the exact sequence you followed (with indicated the Zone under test) and the log, I can give a look and try to complete the supprot for these cases.
i observe a strange behaviour for my dimmed lights:
when i switch them ON or OFF from a physical switch everything works fine, no problems.
but when i let them switch by a command send from a rule i have to pay attention, if i send command OFF to a dimmed light that is already OFF then i cannot switch it ON again with a ON-command, only with a command that sends a level it works (although this works from a physical switch).
for example a log:
==> /var/log/openhab/events.log <==
2023-04-08 14:32:51.500 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'iBuero_Li' received command ON
2023-04-08 14:32:51.503 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'iBuero_Li' predicted to become ON
2023-04-08 14:32:51.512 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'iBuero_Li' changed from 0 to 100
2023-04-08 14:32:51.605 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'iBuero_Li' changed from 100 to 77
==> /var/log/openhab/events.log <==
2023-04-08 14:32:53.585 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'iBuero_Li' received command OFF
2023-04-08 14:32:53.590 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'iBuero_Li' predicted to become OFF
2023-04-08 14:32:53.610 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'iBuero_Li' changed from 77 to 0
==> /var/log/openhab/HABApp.log <==
2023-04-08 14:32:55.832 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'iBuero_Li' received command OFF
2023-04-08 14:32:55.834 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'iBuero_Li' predicted to become OFF
==> /var/log/openhab/events.log <==
2023-04-08 14:32:57.581 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'iBuero_Li' received command ON
2023-04-08 14:32:57.584 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'iBuero_Li' predicted to become ON
2023-04-08 14:32:57.594 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'iBuero_Li' changed from 0 to 100
2023-04-08 14:32:57.597 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'iBuero_Li' changed from 100 to 0
first i sent command ON - light switches ON with the known behaviour that it changes always to 100 an then immediately back to the last set dimmer level
then i sent command OFF - light switches OFF (changes to 0)
then again i sent command OFF although light is already OFF
after that when i try to switch ON again it changes to 100 and immediately back to 0 AND now i cannot switch it on with a switch from sitemap in basic-ui, also not with a slider from basic-ui on my windows-computer, strange but with the same slider from basic-ui on my mobile i can switch it ON again and then it works again
this happens no matter if the command is sent from habapp or dsl rule. has anybody else realized this?
i am on openhabian with oh 4.0.0.m1 but i think i already have seen this with oh3.2
i continuously see error messages like this in the log, seems to come from heating:
==> /var/log/openhab/openhab.log <==
2023-04-10 10:25:20.296 [ERROR] [ore.common.registry.AbstractRegistry] - Cannot inform the listener "org.openhab.core.thing.internal.ChannelLinkNotifier@18710eb" about the "UPDATED" event: UID segment 'openwebnet:speedFanCoil' contains invalid characters. The last segment of the channel UID must match the pattern '[\w-]*|[\w-]*#[\w-]*'.
java.lang.IllegalArgumentException: UID segment 'openwebnet:speedFanCoil' contains invalid characters. The last segment of the channel UID must match the pattern '[\w-]*|[\w-]*#[\w-]*'.
at org.openhab.core.thing.ChannelUID.validateSegment(ChannelUID.java:136) ~[?:?]
at org.openhab.core.common.AbstractUID.<init>(AbstractUID.java:76) ~[?:?]
at org.openhab.core.thing.UID.<init>(UID.java:66) ~[?:?]
at org.openhab.core.thing.ChannelUID.<init>(ChannelUID.java:59) ~[?:?]
at org.openhab.core.thing.internal.ThingImpl.getChannel(ThingImpl.java:125) ~[?:?]
at org.openhab.binding.openwebnet.internal.handler.OpenWebNetThermoregulationHandler.channelExists(OpenWebNetThermoregulationHandler.java:583) ~[?:?]
at org.openhab.binding.openwebnet.internal.handler.OpenWebNetThermoregulationHandler.refreshDevice(OpenWebNetThermoregulationHandler.java:613) ~[?:?]
at org.openhab.binding.openwebnet.internal.handler.OpenWebNetThermoregulationHandler.requestChannelState(OpenWebNetThermoregulationHandler.java:163) ~[?:?]
at org.openhab.binding.openwebnet.internal.handler.OpenWebNetThingHandler.handleCommand(OpenWebNetThingHandler.java:141) ~[?:?]
at org.openhab.core.thing.binding.BaseThingHandler.channelLinked(BaseThingHandler.java:180) ~[?:?]
at org.openhab.core.thing.internal.ChannelLinkNotifier.lambda$3(ChannelLinkNotifier.java:72) ~[?:?]
at org.openhab.core.thing.internal.ChannelLinkNotifier.call(ChannelLinkNotifier.java:96) ~[?:?]
at org.openhab.core.thing.internal.ChannelLinkNotifier.added(ChannelLinkNotifier.java:72) ~[?:?]
at org.openhab.core.thing.internal.ChannelLinkNotifier.updated(ChannelLinkNotifier.java:88) ~[?:?]
at org.openhab.core.thing.internal.ChannelLinkNotifier.updated(ChannelLinkNotifier.java:1) ~[?:?]
at org.openhab.core.common.registry.AbstractRegistry.notifyListeners(AbstractRegistry.java:395) ~[?:?]
at org.openhab.core.common.registry.AbstractRegistry.notifyListenersAboutUpdatedElement(AbstractRegistry.java:416) ~[?:?]
at org.openhab.core.thing.link.ItemChannelLinkRegistry.notifyListenersAboutUpdatedElement(ItemChannelLinkRegistry.java:193) ~[?:?]
at org.openhab.core.thing.link.ItemChannelLinkRegistry.notifyListenersAboutUpdatedElement(ItemChannelLinkRegistry.java:1) ~[?:?]
at org.openhab.core.common.registry.AbstractRegistry.updated(AbstractRegistry.java:322) ~[?:?]
at org.openhab.core.common.registry.AbstractRegistry.updated(AbstractRegistry.java:1) ~[?:?]
at org.openhab.core.common.registry.AbstractProvider.notifyListeners(AbstractProvider.java:66) ~[?:?]
at org.openhab.core.common.registry.AbstractProvider.notifyListenersAboutUpdatedElement(AbstractProvider.java:91) ~[?:?]
at org.openhab.core.model.thing.internal.GenericItemChannelLinkProvider.createItemChannelLink(GenericItemChannelLinkProvider.java:108) ~[?:?]
at org.openhab.core.model.thing.internal.GenericItemChannelLinkProvider.processBindingConfiguration(GenericItemChannelLinkProvider.java:76) ~[?:?]
at org.openhab.core.model.item.internal.GenericItemProvider.internalDispatchBindings(GenericItemProvider.java:373) ~[?:?]
at org.openhab.core.model.item.internal.GenericItemProvider.internalDispatchBindings(GenericItemProvider.java:342) ~[?:?]
at org.openhab.core.model.item.internal.GenericItemProvider.processBindingConfigsFromModel(GenericItemProvider.java:213) ~[?:?]
at org.openhab.core.model.item.internal.GenericItemProvider.modelChanged(GenericItemProvider.java:408) ~[?:?]
at org.openhab.core.model.core.internal.ModelRepositoryImpl.notifyListeners(ModelRepositoryImpl.java:301) ~[?:?]
at org.openhab.core.model.core.internal.ModelRepositoryImpl.addOrRefreshModel(ModelRepositoryImpl.java:139) ~[?:?]
at org.openhab.core.model.core.internal.folder.FolderObserver.checkFile(FolderObserver.java:222) ~[?:?]
at org.openhab.core.model.core.internal.folder.FolderObserver.processWatchEvent(FolderObserver.java:266) ~[?:?]
at org.openhab.core.internal.service.WatchServiceImpl$Listener.notify(WatchServiceImpl.java:286) ~[?:?]
at org.openhab.core.internal.service.WatchServiceImpl.lambda$6(WatchServiceImpl.java:271) ~[?:?]
at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) ~[?:?]
at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179) ~[?:?]
at java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:992) ~[?:?]
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) ~[?:?]
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) ~[?:?]
at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) ~[?:?]
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) ~[?:?]
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?]
at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596) ~[?:?]
at org.openhab.core.internal.service.WatchServiceImpl.doNotify(WatchServiceImpl.java:271) ~[?:?]
at org.openhab.core.internal.service.WatchServiceImpl.notifyListeners(WatchServiceImpl.java:265) ~[?:?]
at org.openhab.core.internal.service.WatchServiceImpl.lambda$4(WatchServiceImpl.java:232) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) ~[?:?]
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:1136) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]
at java.lang.Thread.run(Thread.java:833) ~[?:?]
hi Stefan this is indeed a bug , I can also reproduce it, although quite a corner case (since it requires sending OFF 2 times). Can you open a new issue for that copying the sequence to reproduce? It should not be a difficult fix and would be included in a next milestone.