did a quick check: the reading of this event is a consequence of having added recently the dateTimeSynch check: probably if you disable dateTimeSynch it will not be printed anymore.
I am skecptical to not log at WARN level for this message: since it’s not documented is in fact an unexpected message from the gateway, so it’s correct to warn the user.
If you are brave enough you could ask for some info about this DIM/message in the official OWN forum from BTicino, but usually they respond they do not provide support for obsolete HW, like MH202
first of all it is not a error but a warning so i thought it is not worth mind about it too much. but i also can see messages like this in my logs, actually when checking my enviroment only for dimers:
not quite sure but i realized some times that different gateways send commands in different ways. one example i noted for dimmers. if i send a timed-light command (from elsewhere) the bticino binding does not set the state for switches and dimmers at the end of the time back to OFF
the f454 webserver sends this command like:
*#1*45#4#01*4*100*1##
but the mh200n sends this command like:
*#1*45#4#01*1*100*1##
i send this command manually and this is exact the command that causes the warning in my log
it was probably because according to OWN specs by BTicino, the possibile values for dry contact are in fact ON/OFF.
They refer to general porpose devices that can be used in different settings, some of them more aligned with ON/OFF , other with OPEN/CLOSE
Re-checked the whole config, no master was set on my system.
I have now set the burglar alarm control unit as master and everything works fine.
I don’t know if the master’s behaviour is correct, but if I manually set a time value from the touch screen, the master also changes it to the wrong time. In any case, after a while, when the master broadcasts the wrong time on the bus, the binding performs the check and sets back the value on all the devices to the correct time.
I just published on the Marketplace a new 4.1.0.beta1 version of the binding that should fix handiling of general/area events for lights: now if a GEN / AREA on/off event is sent on the BUS, lights will update their state.
it does not fix yet updates if you have defined GEN / AREA things: these things will not be updated, only single light things are updated (working on it…)
events for GROUPs (where = #group-number) and defining GROUP things should work already, also in previous binding versions
this beta does not fix handling of GEN / AREA events for Automations (WHO=2). If the approach works, I will extend it also to automations
In my system there is no area defined but, a couple of physical switch that send a light gen ON/OFF. If I’m not wrong, one is direct CEN ON/OFF while the other activates a MH200N scenario that switches the lights OFF.
If this is the kind of test you need, I will give it a try. Any log collection needed?
if these CEN or scenario do actually send a *1*0*0## command on the BUS, then yes this should work now and the single lights on the OH side should be update accrodingly.
If it works no log is required, if it does not work then the usual DEBUG level log is useful
yes you can create general/area things-items to send commands, but , as said in my notes above, their state will not be updated yet, only single light things are updated now
I could be able to test this, but it may take me some time, life is a bit busy right now.
I could test GENERAL and GROUP commands for lights. I am not using AREA commands.
One question: when you say GROUP commands should also work with previous binding, how does that work exactly? How does the binding know which GROUP a Thing belongs to?
if a on/off message is sento to a group on the BUS, for example *1*0*#21## = switch off group #21, then on the BUS off event messages will be also generated for all members of that group, thus the binding can easily update individual light things-items to off.
This is not true for GENERAL and AREA light events, so they must be handled explicitly by the binding.
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
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:
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?
