[openWebNet/BTicino] openHAB3

OK thanks… So far it seems to be some (?) MH202 scenarios with switches in the only if conditions that fail to work after OH restart. I was wondering if I disable the thing before reboot and reenable it after reboot maybe the binding will not try to synchronise? Could it be that the sync request overwhelms the MH202? I tried toggling the effected switches used in the MH202 ‘only if’ scenario conditions but it did not appear to work. Only rebooting the MH202 gets it all working again.

I would consider moving some MH202 scenarios to OH but I need the dry contacts to work and some are mission critical and I still view OH as developmental and more likely to fail. The MH202 maybe be dumb but it works reliably works except now for the OH interference.

M

No, I can’t do anything, Up & down trigger does not work, no reaction.

By the way, here are my things & items configuration:

.things

Bridge openwebnet:zb_gateway:donglelegrand  [serialPort="COM3"]
{
	zb_automation voletsroulantthibault "ZigBee Automation Volets Thibault (WHERE=767876301#9)"		[ where="767876301#9"]
	zb_automation voletsroulantclement "ZigBee Automation Volets Clément (WHERE=767877401#9)"		[ where="767877401#9"]
	zb_automation voletsroulantparents "ZigBee Automation Volets Parents (WHERE=767878401#9)"		[ where="767878401#9"]
	zb_automation voletsroulantbureau "ZigBee Automation Volets Bureau (WHERE=767876801#9)"			[ where="767876801#9"]
}

.items

Group gVolets "Volets Roulants"																				<rollershutter>
	Rollershutter ChambreThibault_Shutter		"Volets Chambre Thibault"                			 		<rollershutter>	(gVolets,gGoogleHome)				{ga="Blinds",channel="openwebnet:zb_automation:donglelegrand:voletsroulantthibault:shutter"}
	Rollershutter ChambreClement_Shutter		"Volets Chambre Clement"           			      			<rollershutter>	(gVolets,gGoogleHome)				{ga="Blinds",channel="openwebnet:zb_automation:donglelegrand:voletsroulantclement:shutter"}
	Rollershutter ChambreParents_Shutter		"Volets Chambre Parents"           			      			<rollershutter>	(gVolets,gGoogleHome)				{ga="Blinds",channel="openwebnet:zb_automation:donglelegrand:voletsroulantparents:shutter"}
	Rollershutter ChambreBureau_Shutter			"Volets Bureau"              						   		<rollershutter>	(gVolets,gGoogleHome)				{ga="Blinds",channel="openwebnet:zb_automation:donglelegrand:voletsroulantbureau:shutter"}

There is no error in the logs.

how do you send UP/DOWN commands ? via WebUI ? or other? Why there is no shutterRun parameter configured in your .things file ?

I do it via the MainUI.
Example in one room.

component: oh-rollershutter-item
config:
  icon: oh:blinds
  item: ChambreBureau_Shutter
  title: Volets Bureau
  vertical: false

I never parametered any shutterRun parameter, so default value used “Auto”
Only “issue” is that when I save the .items file (when improving on my OH3 with new items), I need to re-start Openhab to have it working again. It’s not a big deal. When playing with my OH instance, I just need to not forget to re-start the server, otherwise, next morning, I need to use switches on the wall to open shutters, or I stay in the dark :rofl:

Massi has been busy

Do I just need the one kar file and latest snapshot?

Thanks Massi

@massi I will test this today/weekend

See info here:

Starting from OH 3.2.0.M5 you should be able to install it from Marketplace; dependencies should be auto-resolved.

But you should remove other versions.

No issues so far. All my dry contacts sensors are back in operation. No changes were needed to OH2 things, items or rules. Nice :slight_smile:

Just noticed my heating valves state only update on restart. After that they do not update.

thing

Thing bus_thermo_zone 6 "Office" [ where="6" ]

item

Switch Office_HeatingValve "Office heating" <radiator> {channel="openwebnet:bus_thermo_zone:gateway:6:heatingValves"}

openHAB 3.2 snapshot

I spotted a small bug that explains the log message you reported above, but even with this bug the control and trigger of the shutters via USB dongle should continue working, so I cannot reproduce your situation.
It would be useful if you set log level to DEBUG for openwebnet binding and openwebnet4j lib and then change the .items file and copy the entire openhab.log and send to me via Private Message.

This is because 99/4-zone Thermo is not fully supported yet.
See also the thread on Marketplace to provide feedback on 99/4-zone support.
It’s useful if you open a new issue in GitHub and there copy paste the own messages you see in the log (or in the BTicino official client) when the heating starts because temp goes below threshold.

Hi,

I am simplyfing my logs and removing INFO level entries unless I specifically create a log entry from a rule.

I needed to set


log:set WARN org.openhab

to get rid of this which occurs every 15mins

2021-12-18 09:45:16.748 [INFO ] [al.discovery.BusGatewayUpnpDiscovery] - Found device urn:dial-multiscreen-org:device:dial:1

2021-12-18 09:45:16.750 [INFO ] [al.discovery.BusGatewayUpnpDiscovery] -                               |- AEOTA (Amazon)

2021-12-18 09:45:16.989 [INFO ] [al.discovery.BusGatewayUpnpDiscovery] - Found device urn:dial-multiscreen-org:device:dial:1

2021-12-18 09:45:16.990 [INFO ] [al.discovery.BusGatewayUpnpDiscovery] -                               |- AEOTA (Amazon)

2021-12-18 10:00:19.317 [INFO ] [al.discovery.BusGatewayUpnpDiscovery] - Found device urn:dial-multiscreen-org:device:dial:1

2021-12-18 10:00:19.319 [INFO ] [al.discovery.BusGatewayUpnpDiscovery] -                               |- AEOTA (Amazon)

2021-12-18 10:00:19.486 [INFO ] [al.discovery.BusGatewayUpnpDiscovery] - Found device urn:dial-multiscreen-org:device:dial:1

2021-12-18 10:00:19.487 [INFO ] [al.discovery.BusGatewayUpnpDiscovery] -                               |- AEOTA (Amazon)

2021-12-18 10:15:21.904 [INFO ] [al.discovery.BusGatewayUpnpDiscovery] - Found device urn:dial-multiscreen-org:device:dial:1

2021-12-18 10:15:21.906 [INFO ] [al.discovery.BusGatewayUpnpDiscovery] -                               |- AEOTA (Amazon)

2021-12-18 10:15:22.148 [INFO ] [al.discovery.BusGatewayUpnpDiscovery] - Found device urn:dial-multiscreen-org:device:dial:1

2021-12-18 10:15:22.150 [INFO ] [al.discovery.BusGatewayUpnpDiscovery] -                               |- AEOTA (Amazon)

Is it normal to use org.openhab? It’s the only logged item which required me to do that!

M

Well you could have used:
log:set WARN org.openhab.binding.openwebnet.internal.discovery
to set to warn just the discovery part.

In any case these discovery-related logs have been lowered to debug level in the upcoming 3.2 release (they were very very useful while debugging bticino gateway device discovery, which is stable and mature now).

1 Like

@massi

I rebooted MH202 and then loaded the new 3.3.0.M1.beta1.bootsynch. I didn’t seem to need any dependencies. Not seen any issues so far but will know better tomorrow when a morning scenario with ‘only if’ conditions often fails to run after reloading the binding.

Note: I had a lot of problems when installing and uninstalling bindings , openwebnet and amazonechocontrol usually give me a headache. Sometimes all bindings then fail to reload. Repeated reboots seem to eventually fix the problem. This latest one casue no trouble at all.

I have an idea. Would it be possible for the binding to act as a master clock for openwebnet?

Request submitted;

Problem:
MH202 and Screen10 does not use an NTP server. After resuming from a power outage the BUS clocks are no longer correct. Also, daylight saving has to be done manually.

Solution:
The openHAB system clock is always correct, it syncs with ntp severs and its easier to use an UPS to avoid power interupts. So, the openHAB binding would be the better choice for the BUS master clock with other BUS clocks acting as slaves (this is an optional setting in the config for MH202, Screen10)

@m4rk can you do a test using the official bticino client and send this message to MH202/Screen10 and see if their time is set accordingly?
*#13**#0#hh*mm*ss*001##
where hh, mm, ss are hour, minutes and seconds (always use 2 digits: hh=01 mm=14 to set time to h01:14 in the morning.

I set the MH202 to slave. Screen10 was already slave. Then sent every 10 sec

*#13**#0#20*00*00*001##

No time change seen on either MH202 or Screen10

set MH202 back to master and I see this:

Looks like the current time every 30sec

Try this, docs where wrong:

*#13**#0*20*00*00*001##

that worked. Even with MH202 as master the S10 updated to new time. The S10 didn’t correct the time later even after I saw MH202 send out the time but it stayed plus some minutes to the time I manually sent

Seems to trigger a cascade of other events too

*#13**#0*12*00*00*001##

edit… OK the following events are the 99zone thermo central unit. It also picks up the new time.

Docs seem ok here

who13

https://developer.legrand.com/documentation/open-web-net-for-myhome/

I figured out why the MH202 time wasn’t being used after sending the who13… it was because I hadn’t seen that the MH202 master clock also got updated with the time I sent… The 99zone unit also gets updated.

If I send what22 time and date then is seems the MH202 responds by sending out its time and date thereby overriding the one I sent. Seems in this case it acts like a master clock