You can do more with OH but on the other hand MH202 scenarios are good enough for most tasks and are more reliable. MH202 is simpler but very stable. Maybe OH is much better now it is OH3 but I am stuck on OH2.5 due to the lack of support in the newer binding for things that were previously supported by the old binding. If I get to OH3 and it proves to be rock solid then I may use OH for direct control of critical things.
yes, thermo would be a great improvement, i´m also looking forward when it will be implemented 
1 Like
I agree blind position should be UNDEF after reboot/reconnect (and maybe >1min is passed).
Then one can apply a rule to fully open/close the blind to restore position, but I would avoid to do this automatically by the binding (even if it’s absolutely possible) to avoid opening the blinds at night , family would not appreciate 
@bastler would you mind opening a new issue for this? Is an easy one and will be fixed for the next Milestone
thanks for this feedback. i hope i did it correct:
As a general comment, bindings should not be updating Item states to UNDEF on initializing. It’s really for flagging connection errors,invalid status, or suchlike problems. If it’s just “don’t know yet”, then don’t give any update.
This allows the user to be in control; if they wish, they can use persistence with restore on startup. (Note that a forced UNDEF will destroy that possibility). Or they don’t use restore, the Item stays NULL until data is available.
hello, not sure if i understand you correct. the thing is that at the moment the state of shutters on reboot always are 0 (open). this is not a requested state from the actor, i think this is set from the binding as init-state.
with this state i have no chance to check if it is the correct state or not. that may make rules work not properly.
i dont want to “update” the shutter-items, i thought it is better to leave them undefined at system start instead of setting a state that could be wrong.
is NULL the state of an item on reboot? so if the state would stay NULL is also fine, this can be catched in a rule and processed.
Yes NULL is the newly reinitialized state of every Item, until somebody does something to it.
(In OH3, “somebody” is often the persistence service restoring by default.)
My point is that the binding should not be doing things to Items in the absence of any information from the device.
thanks for clarification, this was my fault. the state should stay NULL for shutter items. i will edit my issue on github.
So @rossko57 if I understand it correctly, for example in the case of a shutter/blind Thing:
- in case of OH reboot the Item is set to NULL by OH and must stay NULL until the binding knows the new position from the device and thus sets the channel to the new value
- in case of lost/recovered connection to the device the previous blind position is not correct anymore: so the binding should “invalidate” last value and set the channel to NULL until a new position can be calculated
is this behavior the correct one?
Ye-es. If the binding has nothing to say, then say nothing.
Except, there is no prohibition on anything else updating the Item. This is beyond the bindings control.
For a typical OH3 user everything will be being persisted and restore-on-startup by default. If they want this Item excluded from that, it’ll require some configuring.
That’s not your problem as a binding author, but might be something you point out in docs.
That’s completely your choice as binding author. It’s not related to start-up behaviour, you can choose as makes most sense.
It is possible for a binding to set some/all channels to UNDEF in the event of a problem - lost communication, invalid/unexpected data, faulty configuration, etc. The meaning is “I have tried, but can’t supply a sensible value”.
The binding is not obliged to do that, though. It can simply not provide an update over the channel, at all. You might decide that lost communication is more of a Thing status update instead.
Which might be “best” depends on the technology involved and the nature of the ‘problem’.
Not quite - NULL means uninitialized, just “no-one knows - yet”. That’s not necessarily a problem at all.
UNDEF is subtly different, “tried, but something is wrong just now.”.
It’s more or less a rule that a binding should never update to NULL, it is not the binding’s job to initialize Items which is what that is for.
Thanks @rossko57 for the detailed explanation.
So still my doubt is: suppose the blind is at 50%. Then the binding looses the connection to the gateway that handles the communication with the physical blind actuator device.
Then maybe someone in the house moves the blind physically to 70% but since the communication with OH is lost, OH cannot be updated about the new position.
Then the connection is resumed, but the gateway has no way to know the position of the blind until it’s rolled full up or down (position is estimated based on movement timing).
So in this case I think the binding should set the position to NULL after the reconnection (“no-one knows - yet”), because restoring the past known value would be wrong.
What do you think?
To repeat
If you feel the binding should be indicating “unknown”, that’s what UNDEF is for. You do know there has been an unexpected break in service.
I couldn’t comment on whether it’s appropriate for that to be used here, I have noidea how your subsystem works.
Hello Massimo (&all), I’m experiencing 2 main issues.
I manage a system composed by 275 things, 136 active Items.
When I was using OH2.5 M3 everything was ok (not energy, not thermo), it was also ok with OH 3.0.2 (yes, w/o the automatic status retrive) , I tried now with 3.1 M3 and M4 and a huge problem occurs when I start OH service… after a while the SCS bus is flooded by a continuous scan. I tried with Linux version in a VM and with openhabian, it’s the same issue. If I downgrade to 3.0.2 the flooding stops. More (but it’s not your fault I know) using 3.1 M3 or M4 the OpenHab application does’nt work reporting a “empty site list”, on iOS as on Android. Any suggestion?
which messages can you see flooding the log? can you copy some examples (always using code fences)?
I do not use openHAB apps, so I cannot tell if in M4 they work or not.
If you think it’s an app problem, I suggest you describe the problem in another thread.
Hi Massimo, it looks like a flooding of scan, it seems the system breaks in scanning to start it again.
Tomorrow I will collect logs.
Ciao Massimo,
for a closer look and “hands on” we could arrange a remote connection towards the system I’m managing so we can talk and test directly. Can it be useful for you? We’re both ITA speaking, this can facilitate the troubleshooting.
found maybe a bug in the version 2.5.0.202101182159 (latest?)
when doing nothing is happening, szenario not being started - but worked in older versions.
String RollOGoeffnen "Rolläden OG öffnen" <network> (gSzenarien) {channel="openwebnet:bus_cen_scenario_control:mybridge:MH202_CEN_scenario:button_32" }
I’m getting the follwing in the log
2021-05-28 08:23:48.265 [WARN ] [penwebnet.message.OpenMessageFactory] - ##openwebnet## unsupported WHAT 32 from frame *15*32*99##
2021-05-28 08:23:48.567 [WARN ] [penwebnet.message.OpenMessageFactory] - ##openwebnet## unsupported WHAT 32#1 from frame *15*32#1*99##
when doing
String RollEGoeffnen "Rolläden EG öffnen" <network> (gSzenarien) {channel="openwebnet:bus_cen_scenario_control:mybridge:MH202_CEN_scenario:button_8" }
All is working fine and no error in the log occuers.
bug in this version? I did no change since years to MH202, the scenario can be started from the Bticino display using the same adress.
EDIT:
Seems as the high scenario id makes troubles (32 is not working, 14 or 8 will work)
I think if you provide some DEBUG level logs would be enough to understand the problem
Debug output:
2021-05-29 11:59:31.079 [DEBUG] [ebnet.handler.OpenWebNetThingHandler] - ==OWN:ThingHandler== handleCommand() (command=PRESSED - channel=openwebnet:bus_cen_scenario_control:mybridge:MH202_CEN_scenario:button_32)
2021-05-29 11:59:31.126 [DEBUG] [et.handler.OpenWebNetScenarioHandler] - ==OWN:ScenarioHandler== handleChannelCommand() (command=PRESSED)
2021-05-29 11:59:31.144 [WARN ] [penwebnet.message.OpenMessageFactory] - ##openwebnet## unsupported WHAT 32 from frame *15*32*99##
2021-05-29 11:59:31.290 [DEBUG] [bnet.handler.OpenWebNetBridgeHandler] - ==OWN== GatewayManagement WHAT = null, ignoring
2021-05-29 11:59:31.447 [DEBUG] [et.handler.OpenWebNetScenarioHandler] - ==OWN:ScenarioHandler== # 99 # sending CEN virtual release...
2021-05-29 11:59:31.449 [WARN ] [penwebnet.message.OpenMessageFactory] - ##openwebnet## unsupported WHAT 32#1 from frame *15*32#1*99##
Is there any way to include the old WHO=4 thermofunction back into the binding?