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.
Good evening everyone, my configuration is Raspberry 4, openhab 4.01 and MH201. I have about 80 switches and 10 zone probes; I also have the 3550 control panel with 99 zones. I’ve been using OH for 4 years now and have never had any major problems. there is one thing I can’t fix in my sitemaps graphics; if the zone probe has a local setting other than 0 the graph has a strange trend when the weekly program settings change.
I just published on the Marketplace a new 4.1.0.beta2 version with further improved handling general/area events for lights.
@m4rk , @the-ninth and @marchino can you check?
Configuration and working example animation follows.
NOTES
bus_on_off_switch, now the new bus_light_group thing type must be usedbus_light_group ALL_lights "All lights" [ where="0" ]
bus_light_group LR_area "Living Room Area 5" [ where="5" ]
bus_on_off_switch LR_switch "Living Room Light 5.1" [ where="51" ]
Ciao Massi,
I will try during the next week, but I need some clarification to better understand how and what to test.
I have always used OH groups to manage a set of lights:
Group:Switch:OR(ON,OFF) GLuci "Gruppo Luci" <if:fxemoji:lightbulb> (GCasa) "Equipment"]
The problem was that the Area/General messages of scenarios or physical devices did not update the status of OH elements. The previous beta version you shared solved this behaviour and OH was able to update itself and have the correct light status.
Group command was not optimised and although all lights could be switched on/off, the command was sent for each element.
If I change the configuration using bus_light_group thing and item, instead of sending a command for each element the Area/General message will be used. Is this correct? This thing should be the one to be covered by test?
this is solved in both beta1 and beta2 versions
correct, now if you send a ON command to a bus_light_group thing configured for an Area like in my Sample configuration, the command is sent only once to the BUS and the area thing/item is also updated correctly
ciao Massi.
The local probe in this case was -3; but this behavior also applies with +3,+2,+1,-2, -1 and protection/antifreeze.
The setpoint (impostata) changes as the time changes and is set on the control unit with TiThermo.
In my graph the problem is on the “Thermo_Zone_WHERE5_Temperatura_impostata”.
Naturally it behaves this way with all similar items.
Ok you should:
Made first test few minutes ago, seem to have the following behaviour:
- Light Group works correctly on all the lights in the area, if switched ON/OFF all the lights are turned ON/OFF
- Light Group inherit correctly single light actions:
- All the lights are OFF
- Light Group 3 is OFF
- I turn ON or OFF Light 32
- Light Group 3 and Light Group 0 (General) are updated correctly
- Light Group does not update single light status correctly:
- Light 32 is ON
- Light Group 3 and Light Group 0 (General) are ON
- I switch OFF Light Group 3
- Light 32 is turned OFF but OH Light 32 status is still ON as well as Light Group 0 OH status that is ON
@massi: let me know if you need any logs or item/thing config
How did you switch off Light Group 3 ? Via a physical button configured for Area=3 ?
Are you sure you have used beta2 version?
If yes, you should send me (via Private Message if you prefer) both item/thing configuration and also DEBUG-level logs to see what happens is this case in particular.
Also is better to talk about Area and not Group (group like Group #22 is in fact another different possibile BUS configuration…)
All tests were performed using only the OH interface and not the physical button.
I still have some problems with installing the Beta version from the marketplace but the file I copied manually is the following “org.openhab.binding.openwebnet-4.1.0.beta2.jar”.
I will send you the log and configuration/thing file via PM shortly.
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.