Hi
I have a problem with v2.50 M4(beta).
I have configured four thermostats but every time I change the target temperature, after a while, the central station 3550 reset these parameters with his settings.
Why? Anyone else with this problem?
Thanks
long time ago that i tried that, so not sure but i know there was a bug in the heating, i think it was with the maual mode and adjust target temp.
but because this binding will expire soon and replaced by a new one this bug will not be eliminated so i think you have to wait for the new openwebnet binding.
I think thermostats are in read-only mode… I have to read the binding definition
I have hacked 2.5.0 latest binding in bytecode to expire in 2050. I hope that when the year comes, I wont be hacking bytecode again for it to live “just a little bit longer”. I really admire what you do @massi , but I spent too much effort on setting up temperature control and advanced scenarios to see it go to waste. Some features in my house depend on openhab, e.g. elevator unlocking and garage opening.
Out of respect I will not publicly post the hacked jar here, but if anybody needs it, bookmark this post and on January 14th 2021 at 15:00, come to me, I will save your ruined day.
5 Likes
Did you have a link or a procedure? Thanks, I update all but in case off… 
I do not want to spam this thread with details, but the said check is in org.openhab.binding.openwebnet-2.5.0.jar/openwebnet-lib-0.9.23.jar/org/openwebnet/AbstractOpenGateway.java , method protected final boolean a() and there is a check for date > 2021-01-14 15:00:00 GMT. I used JByteMod to do the deed.
@Massi I sadly have to agree with @michnovka - I am happy to test the binding but I have too many CEN+ commands in my setup with associated rules. If you can add in this functionality then I can help with the testing. Otherwise I think we are going to end up all using different bindings.
@michnovka it would be nice if you could publish the unexpirable binding before january please!!
Thanks
I was asked in the past by @massi to not publish modified/decompiled versions of hid binding, and I will respect that. Send me a PM and I will send you the file. I still believe @massi will eventually provide the same legacy binary without expiration, so I dont want to go behind his back. I just made an insurance for me.
The CEN+ commands are essential for me to handle lot of automation tasks from the Bticino tablet, so without them being ported, I cannot even consider updating.
Still looking forward to OpenHAB 3.0
1 Like
I think so.
Maybe I have a partial solution. If I create a rule that every time the “targetTemperature” change without his relative item, the system set the parameter with the old value.
mmmm, It’s a partial solution really…my thermostats central is scheduled every 15 minutes and I think the thermostats sends the value every time: in this case your rule runs every 15 minutes ?!?
Why does the binding even need to expire? As long as its clear on the web page that it is a unspupported old version then if people choose to use it then it should be their decision.
For me I will still use old version until the new is as good as it with the same or more supported features. Luckily for me i have a spare RaspberryPi and use that for testing the new version but I will still run my old version in parallel.
Exacly, I dont’ like it very much but it’s the only option…
P.S. My thermostats central is scheduled every 5 minutes 
Install OpenHab 2.5.10 with official OWN binding with Legrand USB stick.
Problem still exists. I turn on the light, and the current status remains NULL, although the light turns on.
Thing file line:
zb_on_off_switch2u myzigbeeswitch_zal "Зал"@"Зал" [ where="769636100#9" ]
Log:
2020-10-29 10:24:23.925 [DEBUG] [ebnet.handler.OpenWebNetThingHandler] - handleCommand() (command=ON - channel=openwebnet:zb_on_off_switch2u:myZBgateway:myzigbeeswitch_zal:switch_02)
2020-10-29 10:24:23.928 [DEBUG] [et.handler.OpenWebNetLightingHandler] - handleSwitchCommand() (command=ON - channel=openwebnet:zb_on_off_switch2u:myZBgateway:myzigbeeswitch_zal:switch_02)
==> /var/log/openhab2/events.log <==
2020-10-29 10:24:23.879 [ome.event.ItemCommandEvent] - Item 'Switch_zal_center' received command ON
2020-10-29 10:24:23.903 [nt.ItemStatePredictedEvent] - Switch_zal_center predicted to become NULL
==> /var/log/openhab2/openhab.log <==
2020-10-29 10:24:28.343 [DEBUG] [bnet.handler.OpenWebNetBridgeHandler] - ownId=1.769636102#9
2020-10-29 10:24:28.346 [DEBUG] [bnet.handler.OpenWebNetBridgeHandler] - ownId=1.769636102#9 has NO DEVICE associated, ignoring it
I change where from “769636100#9” to “769636102#9”. Second button become work fine. But when I switch first button, I see the error:
2020-10-29 10:32:07.047 [DEBUG] [bnet.handler.OpenWebNetBridgeHandler] - ownId=1.769636101#9
2020-10-29 10:32:07.049 [DEBUG] [bnet.handler.OpenWebNetBridgeHandler] - ownId=1.769636101#9 has NO DEVICE associated, ignoring it
I cannot configure both buttons of zb_on_off_switch2u at the same time.
@Luca95 could you possibly elaborate how you connected the HC4451 to the gateway?
As far as I see there are no connection possibilities. 
There is a mistake. My central temperature control unit is the HC4695. I had created a dedicated section ([BTicino/OpenWebNet] Thermostat HC4695 Setpoint/Target Temperature problems).
Hi all, how can I install two OH instances on the same raspi?
I have installed an OH instance with official release, but it doesn’t support the thermoregulation, that I have in my house. So I will try, if it’s possible, to test the beta version on the same raspi with another instance of OH.
I’m using an old TS as gateway.
Thanks
I am working on the Alexa voice control again. Issuing a STOP command was always a problem but there was a work around using mode controller v3 tags. However for this binding I also had to create a rule to translate the Alexa command to sendCommand(STOP) to the RollerShutter item.
I am looking at this issue again and was hoping to get rid of the rule but did not find a way.
For the mode controller the item type needs to be String but the binding doesn’t recognise the command sent to Item type String but my rule triggers and so I know the commands are being received for the string type
eg
String OfficeShutter_Command "Office blind M" (gOfficeBlind, gShutterCommand) { channel="openwebnet:bus_automation:gateway:55:shutter" , alexa="ModeController.mode" [supportedModes="STOP=STOP,UP=UP,DOWN=DOWN", autoupdate="false"] }
If I change the type to RollerShutter then Alexa does not find the device. So to use the mode controller the item type has to be String type… catch 22
Does the binding only work RollerShutter type? Could it be made to work with String type for ‘Modes’ and the eg commands UP, DOWN, STOP ? I have seen other bindings that can accept mode, string type, commands
As a test I tried connecting to the binding with an Item as String type. I see in the logs the commands are sent but there is no response from the binding. So, this does not work.
[INFO ] [clipse.smarthome.model.script.Blinds] - UP command sent to Office_RollerShutter
[INFO ] [clipse.smarthome.model.script.Blinds] - STOP command sent to Office_RollerShutter
[INFO ] [clipse.smarthome.model.script.Blinds] - DOWN command sent to Office_RollerShutter
The rule that makes Alexa commands work with the openwebnet binding is below. This would not be necessary if the binding accepted commands.
rule "Alexa command" // Converts String command to RollerShutter command
when
Member of gShutterCommand received command
then
val itemName = new StringBuilder()
itemName.append = (triggeringItem.name.replace("Shutter_Command", ""))
itemName.append('_RollerShutter')
sendCommand(itemName.toString, receivedCommand.toString)
logInfo("Blinds", receivedCommand + " command sent to "+ itemName )
end
items
Group gOfficeBlind "Office blind" {alexa="Endpoint.EXTERIOR_BLIND"}
String OfficeShutter_Command "Office blind command" (gOfficeBlind, gShutterCommand) {alexa="ModeController.mode" [supportedModes="STOP=STOP,UP=OPEN,DOWN=CLOSE", autoupdate="false"], channel="openwebnet:bus_automation:gateway:55:shutter" } //friendlyNames="@Setting.Opening" @Value.Open @Value.Close
Rollershutter Office_RollerShutter "Office blind controller [%d %%]" <blinds> (gOfficeBlind, gAllBlinds) {alexa="RangeController.rangeValue" [supportedRange="0:100:10", unitOfMeasure="Percent", actionMappings="Close=100,Open=0,Lower=(+10),Raise=(-10)", stateMappings="Closed=100,Open=0:99"], channel="openwebnet:bus_automation:gateway:55:shutter" }
This will exceute the correct command for all shutters and produce log entries like this:
DOWN command sent to Office_RollerShutter
STOP command sent to Office_RollerShutter
UP command sent to Lounge_RollerShutter
STOP command sent to Lounge_RollerShutter
Note … I also found this works :
sendCommand(itemName.toString, receivedCommand.toString)
but this doesn’t
sendCommand(itemName.toString, 'STOP')
The results looks the same in the log!!
Note… as posted previously for voice commands
The Alexa mode command works if it’s said like this :
Set office blind to stop.
But if you want to simply say
stop office blind
In this case you need to use an Alexa routine work around to use a more natural phrase. This can be a pain because you will need a routine per blind and the devices in it are lost at every device remove all, discover cycle you do for Alexa.
I have a problem that maybe someone knows the answer to or can test for me.
To get from running MH202 scenarios to openHAB I sometimes use what I call virtual items. These switches that are placed in a scenario and send an Off or On commands. The actuators do not exist, so its cheap to do, and I call these virtual switches. They just send a command onto the BUS and the openwebnet binding sees andcan then trigger a rule.
eg
item
Switch SunnyCills1_VirtualSwitch "Virtual switch: Sunny cills 1" <blinds> {channel="openwebnet:bus_on_off_switch:gateway:0812:switch"}
Thing
//Virtual switches
Thing bus_on_off_switch 0812 "Sunny cills1" @"Test" [ where="0812" ]
rule that is triggered
rule 'Moving to sunny cills1'
when
Item SunnyCills1_VirtualSwitch changed to ON
then
logInfo("Blinds",'Sunny cills1')
AlexaStatusAnnouncement.postUpdate('Moving blinds to sunny cills position one')
BlindPositionMode.postUpdate('Sunny cills1')
BlindPositionModeChanged_Timestamp.postUpdate(new DateTimeType)
json = '{
"time":' + Long::toString(now.millis) + ',
"tags":["BlindControl"],
"text":"Sunny cills1"
}'
var output = sendHttpPostRequest(url, "application/json", json)
logInfo("Blinds", "Annotation output: " + output)
end
This works and I have others using address 8.1 through to 8.15 and 9.1 through to 9.15 which are mixture of real actuators and non existent vritual actuators.
If I use any other adress outside the above range then the virtual switch trick doesn’t work.
One clue is that if I use myHomeSuite to send a command I get a success for my working virtual switches and a fail for the non working ones.
The virtual switch idea works great but I have now run out of working addresses.
Has anyone got any clues as to what is going on or what tests i could run to check this further and use other addresses beyon 8.xx to 9.xx.
I suppose I could try sending virtual CEN or CENP commands instead.
Maybe I didn’t understand something, but why register the address of the virtual device?
My virtual switch
Switch neptun1_close "Ванна кран"
And I do not fill in the Things file.
I do a create a Thing. Its online for those virtutal devices that work and offline for those that don’t. I’m guessing that the binding responds to BUS commands and hence they succeed when testing for myHomeSuite but only for address A between 8 and 9. Something odd with the binding for 8-9 or maybe the way I set it up?
I was testing the addresses with Sunny cills 1 and then it dissapeared from Things config. Restarted OH and it reappeared They shows as offline in Things config until the switch is activated either from OH or test send from myHome Suite
Adresses 8.12, 8.13, 8.14 do not physically exist!
