I confirm that it’s working!!!
I don’t know if the following information from the logs are correct but, probably I have some AREA defined in my system I didn’t know:
---- LightAutomHandlersMap ----
- Area: 1
- 1.12 1.11
- Area: 2
- 1.23 1.21
- Area: 3
- 1.34 1.35 1.32 1.33 1.31
- Area: 9
- 1.92 1.91 1.98
# getAllHandlers: 1.12 1.11 1.23 1.21 1.34 1.35 1.32 1.33 1.31 1.92 1.91 1.98
# oneH = 1.32
P.s. I had to install the Binding manually, I got an error from the Marketplace
Good news: will wait for few tests from other users to submit a PR to the main OH repository
AREA is implicitly defined by the light/automation address, so for example if a light has WHERE=34 then it means area=3, lightpoint=4.
Could you show examples of a group, area, general things creation using the config files.
Hi
I am not sure if this the correct thread to post this, but I have been using OH 3.2 with the BTincino Openwbnet binding for over a year now with no problems. However I have just updated to OH 4.0.3 and as far as I can see, my LN4691 thermostats are no longer working correctly. I can still read the room temperature and the actuator status correctly. However, while I can read the setpoint temperature if I change it manually on the thermostat, I can no longer write a value to it from OH. The value of the setpoint in the model changes, but it is not written to the thermostat.
I seem to remember that I had a similar problem when I first installed the Btinico binding, but cannot find the solution to the problem.
Do I need to specifically install a new binding (there is now a Beta 4.1.0 version) as I just used the one that was part of the release as is listed as 4.0.3
PJG
Not sure this can help but… I had a similar issue and it was due to unit introduced in OH4.
Check in the log that when you set the value from interface you use the correct unit:
Item 'XXX' received command 20 °
instead of
Item 'XXX' received command 21.5 °C
if the suggestion from @marchino does not work, you should activate DEBUG logging, try to change the temp from OH and post the log here.
Binding 4.1.0.beta1 does not introduce any change on the Thermo part, so it isn’t usefult to try that version.
The problem does seem to be in the Units. Here is an extract from the log when I change the setpoint temperature
2023-11-05 09:16:09.887 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'ThermoOffice_SetpointTemperature' received command 24
2023-11-05 09:16:09.890 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'ThermoOffice_SetpointTemperature' predicted to become 24
2023-11-05 09:16:09.893 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ThermoOffice_SetpointTemperature' changed from 23 °C to 24 °C
The Setpoint receives the command 24 not 24 °C. The predicted value is also 24 not 24 °C. The state change event is correct however with 24 °C. If this is the problem, how do I correct it?
PJG
my sensors dont have that wheel to change the temperature, so i do not have this issue.
how did you set your items, text-based? if yes, check if you have uom configured. my item for example looks like:
Number:Temperature iBuero_Heizung "Büro Ist-Temperatur[%.1f %unit%]" <temperature> (iG_Heizung) { unit="°C", channel="openwebnet:bus_thermo_zone:bticino:Buero_Heizung:temperature" }
this unit i had to add some times ago because i had warnings in my log that are gone now. not sure if it might help in your case.
If the problem is not with units of measure (see also @bastler suggestion), then the DEBUG level log is required.
The log you posted above is INFO and does not help.
See my link above on how to set log correctly for both the openwebnet binding and the openwebnet4j lib.
Massimo
I have set up logging as you suggested. Here is the result for attempting to change setpoint to 22C
==> /var/log/openhab/openhab.log <==
2023-11-05 11:24:38.431 [DEBUG] [ernal.handler.OpenWebNetThingHandler] - handleCommand() (command=22 °C - channel=openwebnet:bus_thermo_zone:MyHomeGateway:1:setpointTemperature)
2023-11-05 11:24:38.433 [DEBUG] [penwebnet4j.message.Thermoregulation] - ====TEMPERATURE 22.0 --> : <0220>
2023-11-05 11:24:38.434 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-CMD -------> *#4*1#1*#14*0220*1##
2023-11-05 11:24:38.435 [INFO ] [j.communication.BUSConnector.message] - BUS-CMD ====>>>> `*#4*1#1*#14*0220*1##`
2023-11-05 11:24:38.436 [DEBUG] [nwebnet4j.communication.FrameChannel] - -FC-BUS-CMD |<-- NO DATA (size=0)
2023-11-05 11:24:38.437 [INFO ] [j.communication.BUSConnector.message] - BUS-CMD <<<<==== X [no frames]
2023-11-05 11:24:38.438 [DEBUG] [nwebnet4j.communication.BUSConnector] - ##BUS-conn## Exception: Received null frame while reading responses to command
2023-11-05 11:24:38.438 [INFO ] [nwebnet4j.communication.BUSConnector] - ##BUS-conn## trying NEW CMD connection...
2023-11-05 11:24:38.439 [DEBUG] [nwebnet4j.communication.BUSConnector] - ##BUS-conn## Establishing CMD connection to BUS Gateway on 10.0.0.90:20000...
2023-11-05 11:24:38.441 [DEBUG] [nwebnet4j.communication.BUSConnector] - ##BUS-conn## CMD socket connected
2023-11-05 11:24:38.442 [DEBUG] [nwebnet4j.communication.BUSConnector] - (HS) starting HANDSHAKE on channel BUS-CMD...
2023-11-05 11:24:38.443 [DEBUG] [communication.BUSConnector.handshake] - (HS) ... STEP-1: receive ACK from GW
2023-11-05 11:24:38.446 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-CMD <------- [*#*1##]
2023-11-05 11:24:38.447 [INFO ] [communication.BUSConnector.handshake] - (HS) BUS-CMD <<<<==HS `*#*1##`
2023-11-05 11:24:38.447 [DEBUG] [communication.BUSConnector.handshake] - (HS) ... STEP-1: first ACK received
2023-11-05 11:24:38.448 [DEBUG] [communication.BUSConnector.handshake] - (HS) ... STEP-2: send session request *99*0## ...
2023-11-05 11:24:38.449 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-CMD -------> *99*0##
2023-11-05 11:24:38.450 [INFO ] [communication.BUSConnector.handshake] - (HS) BUS-CMD HS==>>>> `*99*0##`
2023-11-05 11:24:38.451 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-CMD <------- [*#*1##]
2023-11-05 11:24:38.452 [INFO ] [communication.BUSConnector.handshake] - (HS) BUS-CMD <<<<==HS `*#*1##`
2023-11-05 11:24:38.452 [DEBUG] [communication.BUSConnector.handshake] - (HS) ... STEP-2: NO_AUTH: second ACK received, GW has no pwd ==HANDSHAKE COMPLETED==
2023-11-05 11:24:38.453 [INFO ] [nwebnet4j.communication.BUSConnector] - ##BUS-conn## ============ CMD CONNECTED ============
2023-11-05 11:24:38.454 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-CMD -------> *#4*1#1*#14*0220*1##
2023-11-05 11:24:38.455 [INFO ] [j.communication.BUSConnector.message] - BUS-CMD ====>>>> `*#4*1#1*#14*0220*1##` [ REOPEN ]
2023-11-05 11:24:38.496 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-CMD <------- [*#*0##]
2023-11-05 11:24:38.497 [DEBUG] [.openwebnet4j.communication.Response] - ``*#4*1#1*#14*0220*1##`` <<add ``*#*0##``
2023-11-05 11:24:38.498 [DEBUG] [.openwebnet4j.communication.Response] - now: ``*#4*1#1*#14*0220*1##`` <<== `[`*#*0##`]`
2023-11-05 11:24:38.499 [DEBUG] [j.communication.BUSConnector.message] - BUS-CMD <<== `*#*0##`
2023-11-05 11:24:38.499 [INFO ] [j.communication.BUSConnector.message] - BUS-CMD <<<<==== [`*#*0##`]
2023-11-05 11:24:38.500 [DEBUG] [nwebnet4j.communication.BUSConnector] - ##BUS-conn## ^^^^^^^^ USED NEW CONNECTION ^^^^^^^^
I did not understand Bastlers reply. All the setpoint temperatures are created as items automatically in the model
Hope this helps
PJG
this line means the command to change temperature sent by the OpenWebNet binding is not accepted/understood by your gateway.
This the Thing configuration from the WebUI
UID: openwebnet:bus_gateway:MyHomeGateway
label: BUS Gateway
thingTypeUID: openwebnet:bus_gateway
configuration:
host: 10.0.0.90
discoveryByActivation: false
dateTimeSynch: false
passwd: "12345"
port: 20000
location: Laundry
My BTinico Gateway is an F454 Open WebNet
All the 3 thermostats operate stand alone. There is no central controller, 99 nor 4 zone.
PJG
On reflection, this must be an issue relating to the changes from 3.2 to 4, probably the new Java engine. Since the hardware has not changed and it all worked before, I assume that OH is no longer sending the same string of commands. My system is running with OpenHabian on a raspberry pi4. If it would help, I could try re-installing 3.2 on my pc to see what commands are sent with that version.
PJG
What is needed is the Thing configuration for one of the 3 thermostats Things, better the one you already tested in the previous test.
What you pasted here is the bridge Thing (maybe delete and correct the message)
This part in fact has been updated from OH 3, so what I am suspecting is a wrong configuration…
Here is the code for the office thermostat
UID: openwebnet:bus_thermo_zone:MyHomeGateway:1
label: Thermo Office
thingTypeUID: openwebnet:bus_thermo_zone
configuration:
where: 1#1
standAlone: true
bridgeUID: openwebnet:bus_gateway:MyHomeGateway
The other thermostats are configured as 2#1 and 3#1. I think I remember that I had to change these from 1, 2 or 3 which were the default values by adding the #1 manually to each configuration for it to work under OH 3.3
I have tried deleting the Office Thermostat and re-installing it. The default configuration is now 1, but OH will no longer connect to it giving an UNKNOWN message.
PJG
PJG
I have also used the MyHome Suite software to check each thermostat to ensure that they are still set to the correct zones 1,2 and 3 which they are.
PJG
The right configuration should be now (since OH 4) where=1 for Zone 1 for standalone thermostats.
Can you try it?
Deleting the Thing and re-discovery it should also work, but then you have to be sure the same Thing UID is used, otherwise the Item will not be connected anymore and you will have to link again the Item to the Thing channel.
I tried changing the 1#1 to 1 in the properties page, but the device went UNKNOWN when I saved it. Changing back to 1#1 left the device still UNKNOWN so I have lost all the data from the thermostat. I will start again tomorrow reinstalling the thermostats and copying the logs.
PJG
I have managed to get one of the thermostat setpoint functions working with just the configuration 2, rather than 2#1. Great. For your info, I have attached the log file section as it does seem to throw an exception when it first tries to send the command, but then seems to re-establish a connection which then works. Is this a problem or is it what you would expect?
Thanks for the help in getting things going again.
PJG
==> /var/log/openhab/openhab.log <==
2023-11-07 07:51:14.310 [DEBUG] [ernal.handler.OpenWebNetThingHandler] - handleCommand() (command=24 °C - channel=openwebnet:bus_thermo_zone:MyHomeGateway:2:setpointTemperature)
2023-11-07 07:51:14.312 [DEBUG] [penwebnet4j.message.Thermoregulation] - ====TEMPERATURE 24.0 --> : <0240>
2023-11-07 07:51:14.313 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-CMD -------> *#4*2*#14*0240*1##
2023-11-07 07:51:14.314 [INFO ] [j.communication.BUSConnector.message] - BUS-CMD ====>>>> `*#4*2*#14*0240*1##`
2023-11-07 07:51:14.315 [DEBUG] [nwebnet4j.communication.FrameChannel] - -FC-BUS-CMD |<-- NO DATA (size=0)
2023-11-07 07:51:14.316 [INFO ] [j.communication.BUSConnector.message] - BUS-CMD <<<<==== X [no frames]
2023-11-07 07:51:14.317 [DEBUG] [nwebnet4j.communication.BUSConnector] - ##BUS-conn## Exception: Received null frame while reading responses to command
2023-11-07 07:51:14.318 [INFO ] [nwebnet4j.communication.BUSConnector] - ##BUS-conn## trying NEW CMD connection...
2023-11-07 07:51:14.318 [DEBUG] [nwebnet4j.communication.BUSConnector] - ##BUS-conn## Establishing CMD connection to BUS Gateway on 10.0.0.90:20000...
2023-11-07 07:51:14.320 [DEBUG] [nwebnet4j.communication.BUSConnector] - ##BUS-conn## CMD socket connected
2023-11-07 07:51:14.321 [DEBUG] [nwebnet4j.communication.BUSConnector] - (HS) starting HANDSHAKE on channel BUS-CMD...
2023-11-07 07:51:14.323 [DEBUG] [communication.BUSConnector.handshake] - (HS) ... STEP-1: receive ACK from GW
2023-11-07 07:51:14.325 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-CMD <------- [*#*1##]
2023-11-07 07:51:14.326 [INFO ] [communication.BUSConnector.handshake] - (HS) BUS-CMD <<<<==HS `*#*1##`
2023-11-07 07:51:14.326 [DEBUG] [communication.BUSConnector.handshake] - (HS) ... STEP-1: first ACK received
2023-11-07 07:51:14.327 [DEBUG] [communication.BUSConnector.handshake] - (HS) ... STEP-2: send session request *99*0## ...
2023-11-07 07:51:14.328 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-CMD -------> *99*0##
2023-11-07 07:51:14.329 [INFO ] [communication.BUSConnector.handshake] - (HS) BUS-CMD HS==>>>> `*99*0##`
2023-11-07 07:51:14.330 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-CMD <------- [*#*1##]
2023-11-07 07:51:14.331 [INFO ] [communication.BUSConnector.handshake] - (HS) BUS-CMD <<<<==HS `*#*1##`
2023-11-07 07:51:14.332 [DEBUG] [communication.BUSConnector.handshake] - (HS) ... STEP-2: NO_AUTH: second ACK received, GW has no pwd ==HANDSHAKE COMPLETED==
2023-11-07 07:51:14.333 [INFO ] [nwebnet4j.communication.BUSConnector] - ##BUS-conn## ============ CMD CONNECTED ============
2023-11-07 07:51:14.334 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-CMD -------> *#4*2*#14*0240*1##
2023-11-07 07:51:14.335 [INFO ] [j.communication.BUSConnector.message] - BUS-CMD ====>>>> `*#4*2*#14*0240*1##` [ REOPEN ]
2023-11-07 07:51:14.427 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-CMD <------- [*#*1##]
2023-11-07 07:51:14.427 [DEBUG] [.openwebnet4j.communication.Response] - ``*#4*2*#14*0240*1##`` <<add ``*#*1##``
2023-11-07 07:51:14.428 [DEBUG] [.openwebnet4j.communication.Response] - now: ``*#4*2*#14*0240*1##`` <<== `[`*#*1##`]`
2023-11-07 07:51:14.428 [DEBUG] [j.communication.BUSConnector.message] - BUS-CMD <<== `*#*1##`
2023-11-07 07:51:14.428 [INFO ] [j.communication.BUSConnector.message] - BUS-CMD <<<<==== [`*#*1##`]
2023-11-07 07:51:14.428 [DEBUG] [nwebnet4j.communication.BUSConnector] - ##BUS-conn## ^^^^^^^^ USED NEW CONNECTION ^^^^^^^^
2023-11-07 07:51:14.497 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*#4*2*12*0240*3##]
2023-11-07 07:51:14.497 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< `*#4*2*12*0240*3##`
2023-11-07 07:51:14.498 [DEBUG] [rnal.handler.OpenWebNetBridgeHandler] - ownIdFromMessage(`*#4*2*12*0240*3##`) --> 4.2
2023-11-07 07:51:14.499 [DEBUG] [er.OpenWebNetThermoregulationHandler] - @@@@ Thermo.handleMessage(): `*#4*2*12*0240*3##`{THERMOREGULATION-COMPLETE_PROBE_STATUS,w:2,dimValues=[0240, 3]}
2023-11-07 07:51:14.517 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*4*1*2##]
2023-11-07 07:51:14.517 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< `*4*1*2##`
2023-11-07 07:51:14.518 [DEBUG] [rnal.handler.OpenWebNetBridgeHandler] - ownIdFromMessage(`*4*1*2##`) --> 4.2
2023-11-07 07:51:14.519 [DEBUG] [er.OpenWebNetThermoregulationHandler] - @@@@ Thermo.handleMessage(): `*4*1*2##`{THERMOREGULATION-HEATING,w:2}
2023-11-07 07:51:14.542 [INFO ] [nwebnet4j.communication.FrameChannel] - -FC-BUS-MON <------- [*#4*2*0*0217##]
2023-11-07 07:51:14.543 [INFO ] [unication.BUSConnector.message.event] - BUS-MON <<<<<<<< `*#4*2*0*0217##`
2023-11-07 07:51:14.544 [DEBUG] [rnal.handler.OpenWebNetBridgeHandler] - ownIdFromMessage(`*#4*2*0*0217##`) --> 4.2
2023-11-07 07:51:14.544 [DEBUG] [er.OpenWebNetThermoregulationHandler] - @@@@ Thermo.handleMessage(): `*#4*2*0*0217##`{THERMOREGULATION-TEMPERATURE,w:2,dimValues=[0217]}
your code goes here
Great that the thermostat now works with the correct configuration.
In fact this was a required configuration change from OH 3.x to OH 4 in the case of standalone thermostats.
Re-establish of the command connection is perfectly normal since the binding closes the connection after a while if no command is sent.