My heating would only work with the beta, so I stick to that.
I removed the beta and installed the official release just now… I’ll see how it goes 
hi @hyzteric this is strange, as the beta published here at the top of this thread has only one improvement related to basic Scenario (WHO=0), all the rest is equivalent to the official version 3.3.0.Mx (which is about to become the 6-month release 3.3.0 in these days).
Hi @massi yes that is strange. But I just tried again and sure enough, when using the official version, I cannot change my heating set point.
Here is the log when I ask for 19°C instead of 16°C, the command is never send to the BTicino bus and it reverts to 16°C :
2022-06-27 12:11:15.575 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'thermo_1_Living_setTemp' received command 19
2022-06-27 12:11:15.579 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'thermo_1_Living_setTemp' predicted to become 19
2022-06-27 12:11:15.598 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'thermo_1_Living_setTemp' changed from 16 °C to 19 °C
2022-06-27 12:11:19.505 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'thermo_1_Living_setTemp' changed from 19 °C to 16 °C
Also there is that just after, maybe it has to do with the issue :
2022-06-27 12:11:20.236 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘thermo_1_Living_func’ changed from HEATING to GENERIC
really strange, i dont see this in my enviroment. i do not use the function channel because i only have heating, no cooling.
when i change the setpoint temp it looks like:
2022-06-27 18:39:10.285 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'iBuero_Heizung_Set' received command 22.5 °C
2022-06-27 18:39:10.286 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'iBuero_Heizung_Set' predicted to become 22.5 °C
2022-06-27 18:39:10.303 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'iBuero_Heizung_Set' changed from 22 °C to 22.5 °C
(the only difference i see to your log is i have additionally °C logged in the command - you only have a number)
the mode is set to MANUAL if i click PROGRAM then the setpoint temp switches back to the temp that is set in central.
hi! with beta6 for basic scenrio, i’m still having issues when rebooting RPI all things become UNINITIALIZED. Only a binding uninstall and reinstall make them online again.
any one has the same issues with this beta6 binding?
yes, earlier i also had such a problem as i wrote further up. as i dont need the basic scenario who=0 i actually have installed the distribution binding 3.3.0 and that works fine.
Version 3.4.0.beta1.alarm is now published on the Marketplace.
This beta version includes initial support for Alarm (WHO=5).
- Configuration info can be found here.
Alarm channels
Is this for things named BURGLAR_ALARM?
i have these things but i don’t know what they are and what they control in my home…
Thx!
A first support for Burglar Alarm (WHO=5) has been accepted in OH 3.4, which is due end of this month.
I had lost this thread…
Great work dudes!
I’ll test alarm asap and provide any feedback.
Burglard Alarm: everything works smooth and great!! 
Excellent. Did you also try alarm arm/disarm via AUX commands?
Ciao Massi,
I’m arming/disarming my Burglar Alarm via openhab since the availability of CEN+ in OH 2 binding 
Everything works fine, I was using a couple of scenario withing MH200N and a CEN+ rule then, I switched to AUX command as soon as the 3.0 binding added the support.
Thanks again for the great work, missing sound diffusion and full scenario support and my Bticino system will be fully managed via Openhab
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