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:
That would be quite handy and make it maybe possible to implement such a virtual actuator with rules.
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 binding has developed over time. CEN wasn’t supported from the begining and I developed a workaround. If I remember correctly !?
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 
Made another try today:
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.
Test done, sent you all the info via PM.
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
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
one more observation since oh 4.0.0.m1 i make
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.
this has been already fixed: [openwebnet] Thermo: UID segment 'openwebnet:speedFanCoil' contains invalid characters · Issue #14619 · openhab/openhab-addons · GitHub
It will be included in the next milestone.
thank you massimo, great the heating is already fixed, for the dimmer an issue is opened:
Just published on Marketplace version 4.1.0.beta1 to fix handling of general/area light update events
updated on Marketplace version 4.1.0.beta2 to fix handling of general/area light update events and introduce new bus_light_group Things types