what you mean by “full scenario support”? which messages have you in mind?
Version 3.3.0.beta6.scenario-basic is now published on the Marketplace.
This beta version includes initial support for Basic Scenarios (WHO=0).
Probably I am missing something or have misunderstood the changelog above.
I have some CEN+ scenarios in my MH200N. Some of them run a chain of lights off (e.g. where 22 receive off, also where 23 is switched to off) and Openhab correctly detects any change in light status.
A scenario (binded to a physical wall switch) switches off ALL lights and audio amplifiers in each room. In this case, unfortunately, openhab does not detect the change of state of the lights.
[Due to basic scenario support, lack of MH200N WHO 17 support or generally expected?]
Using autodiscovery and activating the switch/scenario, the binding detects a CEN+ thing. I tried to create a rule, that uses the thing, to detect the activation of the scenario and hence adjust the state of the lights, but there seems to be no event/state change detection a part from the auto discovery phase.
[Due to basic scenario support, lack of MH200N WHO 17 support or generally expected?]
it depends on how the scenario is defined and if its activation gets notified as events on the BUS.
It would be useful to have a DEBUG level log (see first post of this thread on how) when the scenario is activated from the physical wall switch.
Scenarios like Basic (WHO=0), CEN (WHO=15) and CEN+ (WHO=25) are all supported by the binding at this point.
Scenes (WHO=17) are in fact not supported yet … nobody asked that until now, in fact.
Hereafter the logs.
The scenario is a CEN+ with ID 1, hence that 25,21 in the logs from row 4. Just after the MH200N scenario is activated with *17*1*1##.
The scenario switch off all the lights, for this reason i suppose also scenarios 17-1-2 17-1-3 that are configured as light OFF cascade are triggered.
All lights off should be *1*0*0##.
After that a list of commands on audio diffusion that should be the amplifiers switch off.
2022-12-17 23:48:18.306 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*#18*51*113*669##]
2022-12-17 23:48:18.308 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *#18*51*113*669##
2022-12-17 23:48:18.310 [DEBUG] [rnal.handler.OpenWebNetBridgeHandler] - ownIdFromMessage(<*#18*51*113*669##>) --> 18.51
2022-12-17 23:48:27.914 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*25*21#1*21##]
2022-12-17 23:48:27.916 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *25*21#1*21##
2022-12-17 23:48:27.917 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*17*1*1##]
2022-12-17 23:48:27.918 [DEBUG] [rnal.handler.OpenWebNetBridgeHandler] - ownIdFromMessage(<*25*21#1*21##>) --> 25.21
2022-12-17 23:48:27.919 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *17*1*1##
2022-12-17 23:48:27.920 [DEBUG] [rnal.handler.OpenWebNetBridgeHandler] - ownId=25.21 has NO DEVICE associated, ignoring it
2022-12-17 23:48:27.920 [DEBUG] [nwebnet4j.communication.BUSConnector] - UNSUPPORTED FRAME: *17*1*1##, skipping it
2022-12-17 23:48:28.190 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*1*0*0##]
2022-12-17 23:48:28.191 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *1*0*0##
2022-12-17 23:48:28.193 [DEBUG] [rnal.handler.OpenWebNetBridgeHandler] - ownIdFromMessage(<*1*0*0##>) --> 1.0
2022-12-17 23:48:28.196 [DEBUG] [rnal.handler.OpenWebNetBridgeHandler] - ownId=1.0 has NO DEVICE associated, ignoring it
2022-12-17 23:48:28.209 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*17*1*3##]
2022-12-17 23:48:28.210 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *17*1*3##
2022-12-17 23:48:28.212 [DEBUG] [nwebnet4j.communication.BUSConnector] - UNSUPPORTED FRAME: *17*1*3##, skipping it
2022-12-17 23:48:28.303 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*#22*2#1*12*0*10##]
2022-12-17 23:48:28.305 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *#22*2#1*12*0*10##
2022-12-17 23:48:28.306 [DEBUG] [nwebnet4j.communication.BUSConnector] - UNSUPPORTED FRAME: *#22*2#1*12*0*10##, skipping it
2022-12-17 23:48:28.320 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*16*13*101##]
2022-12-17 23:48:28.322 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *16*13*101##
2022-12-17 23:48:28.323 [DEBUG] [nwebnet4j.communication.BUSConnector] - UNSUPPORTED FRAME: *16*13*101##, skipping it
2022-12-17 23:48:28.514 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*17*2*1##]
2022-12-17 23:48:28.515 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *17*2*1##
2022-12-17 23:48:28.517 [DEBUG] [nwebnet4j.communication.BUSConnector] - UNSUPPORTED FRAME: *17*2*1##, skipping it
2022-12-17 23:48:28.574 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*17*2*3##]
2022-12-17 23:48:28.575 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *17*2*3##
2022-12-17 23:48:28.577 [DEBUG] [nwebnet4j.communication.BUSConnector] - UNSUPPORTED FRAME: *17*2*3##, skipping it
2022-12-17 23:48:28.603 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*1*0*34##]
2022-12-17 23:48:28.604 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *1*0*34##
2022-12-17 23:48:28.606 [DEBUG] [rnal.handler.OpenWebNetBridgeHandler] - ownIdFromMessage(<*1*0*34##>) --> 1.34
2022-12-17 23:48:28.608 [DEBUG] [al.handler.OpenWebNetLightingHandler] - handleMessage(<*1*0*34##>) for thing: openwebnet:bus_on_off_switch:mh200N:CabArmadio_switch
2022-12-17 23:48:28.610 [DEBUG] [al.handler.OpenWebNetLightingHandler] - 1.34 ONOFF no change
2022-12-17 23:48:28.912 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*22*1#4#1*2#1##]
2022-12-17 23:48:28.913 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *22*1#4#1*2#1##
2022-12-17 23:48:28.915 [DEBUG] [nwebnet4j.communication.BUSConnector] - UNSUPPORTED FRAME: *22*1#4#1*2#1##, skipping it
2022-12-17 23:48:28.943 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*22*21#4#1*5#2#1##]
2022-12-17 23:48:28.944 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *22*21#4#1*5#2#1##
2022-12-17 23:48:28.946 [DEBUG] [nwebnet4j.communication.BUSConnector] - UNSUPPORTED FRAME: *22*21#4#1*5#2#1##, skipping it
2022-12-17 23:48:29.181 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*16*3*111##]
2022-12-17 23:48:29.183 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *16*3*111##
2022-12-17 23:48:29.184 [DEBUG] [nwebnet4j.communication.BUSConnector] - UNSUPPORTED FRAME: *16*3*111##, skipping it
2022-12-17 23:48:29.186 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*22*2#4#1*5#2#1##]
2022-12-17 23:48:29.187 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *22*2#4#1*5#2#1##
2022-12-17 23:48:29.189 [DEBUG] [nwebnet4j.communication.BUSConnector] - UNSUPPORTED FRAME: *22*2#4#1*5#2#1##, skipping it
2022-12-17 23:48:29.722 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*16*3*101##]
2022-12-17 23:48:29.723 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *16*3*101##
2022-12-17 23:48:29.725 [DEBUG] [nwebnet4j.communication.BUSConnector] - UNSUPPORTED FRAME: *16*3*101##, skipping it
2022-12-17 23:48:29.726 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*#22*2#1*12*1*4##]
2022-12-17 23:48:29.728 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *#22*2#1*12*1*4##
2022-12-17 23:48:29.729 [DEBUG] [nwebnet4j.communication.BUSConnector] - UNSUPPORTED FRAME: *#22*2#1*12*1*4##, skipping it
2022-12-17 23:48:29.813 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*22*1#4#2*2#1##]
2022-12-17 23:48:29.815 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *22*1#4#2*2#1##
2022-12-17 23:48:29.816 [DEBUG] [nwebnet4j.communication.BUSConnector] - UNSUPPORTED FRAME: *22*1#4#2*2#1##, skipping it
2022-12-17 23:48:29.852 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*22*21#4#2*5#2#1##]
2022-12-17 23:48:29.853 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *22*21#4#2*5#2#1##
2022-12-17 23:48:29.855 [DEBUG] [nwebnet4j.communication.BUSConnector] - UNSUPPORTED FRAME: *22*21#4#2*5#2#1##, skipping it
2022-12-17 23:48:30.072 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*16*3*121##]
2022-12-17 23:48:30.073 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *16*3*121##
2022-12-17 23:48:30.074 [DEBUG] [nwebnet4j.communication.BUSConnector] - UNSUPPORTED FRAME: *16*3*121##, skipping it
2022-12-17 23:48:30.076 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*22*2#4#2*5#2#1##]
2022-12-17 23:48:30.077 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *22*2#4#2*5#2#1##
2022-12-17 23:48:30.078 [DEBUG] [nwebnet4j.communication.BUSConnector] - UNSUPPORTED FRAME: *22*2#4#2*5#2#1##, skipping it
2022-12-17 23:48:30.702 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*22*1#4#3*2#1##]
2022-12-17 23:48:30.703 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *22*1#4#3*2#1##
2022-12-17 23:48:30.705 [DEBUG] [nwebnet4j.communication.BUSConnector] - UNSUPPORTED FRAME: *22*1#4#3*2#1##, skipping it
2022-12-17 23:48:30.734 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*22*21#4#3*5#2#1##]
2022-12-17 23:48:30.735 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *22*21#4#3*5#2#1##
2022-12-17 23:48:30.736 [DEBUG] [nwebnet4j.communication.BUSConnector] - UNSUPPORTED FRAME: *22*21#4#3*5#2#1##, skipping it
2022-12-17 23:48:30.961 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*16*3*131##]
2022-12-17 23:48:30.962 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *16*3*131##
2022-12-17 23:48:30.964 [DEBUG] [nwebnet4j.communication.BUSConnector] - UNSUPPORTED FRAME: *16*3*131##, skipping it
2022-12-17 23:48:30.965 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*22*2#4#3*5#2#1##]
2022-12-17 23:48:30.967 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *22*2#4#3*5#2#1##
2022-12-17 23:48:30.968 [DEBUG] [nwebnet4j.communication.BUSConnector] - UNSUPPORTED FRAME: *22*2#4#3*5#2#1##, skipping it
2022-12-17 23:48:31.270 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*#18*51*113*606##]
2022-12-17 23:48:31.271 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *#18*51*113*606##
2022-12-17 23:48:31.273 [DEBUG] [rnal.handler.OpenWebNetBridgeHandler] - ownIdFromMessage(<*#18*51*113*606##>) --> 18.51
2022-12-17 23:48:31.591 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*22*1#4#4*2#1##]
2022-12-17 23:48:31.592 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< *22*1#4#4*2#1##
2022-12-17 23:48:31.593 [DEBUG] [nwebnet4j.communication.BUSConnector] - UNSUPPORTED FRAME: *22*1#4#4*2#1##, skipping it
2022-12-17 23:48:31.622 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*22*21#4#4*5#2#1##]
I will make some other tests during next days restarting Openhab but, today I probably found a bug.
If an intrusion is detected, the proper zone status change to “INTRUSION” but, on the next system re-arm (all zones ON) the previously intruded zone status is not reset to a default value (“SILENT”?)
I do that using virtual light actuators. The hardware doesn’t exist but I send an light OFF command to an unused address when the scenario is run. I set openHAB up as though the actuator exists. The thing will show an error until the address is used and then it goes green. The initial comm error doesn’t prevent the openHAB rule from running. Things with and wthout error are shown below by the two arrows
items
Switch SunnyCills1_VirtualSwitch "Virtual switch: Sunny cills 1" <blinds> {channel="openwebnet:bus_on_off_switch:gateway:0812:switch"}
Switch SunnyCills2_VirtualSwitch "Virtual switch: Sunny cills 2" <blinds> {channel="openwebnet:bus_on_off_switch:gateway:0813:switch"}
Switch SunnyCills3_VirtualSwitch "Virtual switch: Sunny cills 3" <blinds> {channel="openwebnet:bus_on_off_switch:gateway:0814:switch"}
Switch OpenMorningCool_VirtualSwitch "Virtual switch: Morning open - cool" <blinds> {channel="openwebnet:bus_on_off_switch:gateway:0914:switch"}
Switch OpenMorningWarm_VirtualSwitch "Virtual switch: Morning open - warm" <blinds> {channel="openwebnet:bus_on_off_switch:gateway:0915:switch"}
things
Thing bus_on_off_switch 0812 "Sunny cills1" [ where="0812" ] //No hardware
Thing bus_on_off_switch 0813 "Sunny cills2" [ where="0813" ] //No hardware
Thing bus_on_off_switch 0814 "Sunny cills3" [ where="0814" ] //No hardware
Thing bus_on_off_switch 0914 "Morning open blinds - cool" [ where="0914" ] //No hardware
Thing bus_on_off_switch 0915 "Morning open blinds - warm" [ where="0915" ] //No hardware
MH202 scenario. If you look carefully I use a few features not mentioned much. Ask if your interested in the general discussion thread. openwebnet general discussions
openHAB rule to do stuff when MH202 scenario runs. Tip >> The commented out // stuff creates a marker in a Grafana chart sothat you can see exactly when the rule ran in the chart data.
rule 'Moving to sunny cills1'
when
Item SunnyCills1_VirtualSwitch changed to ON
then
logInfo("Blinds",'Sunny cills1. Gallery T = ' + Gallery_Temperature.state.toString)
AlexaAnnouncement.postUpdate('The gallery is ' + Gallery_Temperature.state.toString + ' degrees. Moving blinds to position one')
BlindPositionMode.postUpdate('Sunny cills1')
BlindPositionModeChanged_Timestamp.postUpdate(new DateTimeType)
//json = '{
// "time":' + Long::toString(now.toInstant().toEpochMilli()) + ',
// "tags":["BlindControl"],
// "text":"Sunny cills1"
//}'
//sendHttpPostRequest(url, "application/json", json)
end
Not all addresses work the same. So you will need to test. I have raised this in the past but back then there was only me doing this and Massimo was busy enough. In my notes I have >>>>
//Thing bus_on_off_switch 29 “29 test” @“Test” [ where=“29” ] // No hardware. Doesnt work but addresses A8-A9 do without hardware. Sending command works for these in myHomesuite but address not found on a scan
In your use case, do you switch those virtual light actuators only from the BTicino system or also from openHAB? In my testing such virtual light actuators worked fine if only switched from BTicino (apart from the button blinking because their is no actuator feedback), but when I start switching it from openHAB as well, the two systems can get out of sync.
I know that is a big ask, but a cool feature for the binding would be to actually implement a virtual actuator that emulates everything a physical actuator would do. I created a feature request for that:
1 Like
I only use the virtual switches on the BTicino side. I thought @massi was going to implement an Aux thing which you could use to send any BUS commands ??
edit… I just added one of my virtual switches to my sitemap. I toggled it and triggers the openHAB rule I have for that switch. I don’t know if it could also trigger MH202 scenario too??? Maybe I will test. I normally just send a CEN command from openHAB to triggerMH202 scenarios
Yes, that worked for me too, switching of a virtual actuator in openHAB generates an OWN command. But then without the physical actuator, the BTicino controls will get confused and do not send correct commands anymore.
E.g. you switch the virtual actuator off on a Bticino physical control, then on in openHAB and next try to switch it off in Bticino again. The last step won‘t work, you have to press off, on and off again on the physical control for it to send the off.
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?
1 Like
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:
- Alarm armed
- 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).
- Alarm disarmed
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
- 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