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).
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.
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
OH 3.3.0M2 has been published.
For openwebnet it brings:
(these improvements where already available in the mareketplace Beta version, so for the moment the Beta will be unpublished until new improvements are available to be tested)
OH 3.3.0M3 has been published.
For openwebnet it brings:
function (HEATING/COOLING)AT_LEAST_ONE_PROBE_OFF, AT_LEAST_ONE_PROBE_ANTIFREEZE, AT_LEAST_ONE_PROBE_MANUAL, FAILURE_DISCOVERED)Hello thanks for the aux commands that is a god saver. Now it would be nice to get also status of the burglar alarm but we will wait i guess. Just a small correction on your documentation for the automation in the central you wrote
Type in the associated Open Web Net code you want to execute, e.g. 58*#1234## (engage alarm on zones 1,2,3,4)
but its actually
Type in the associated Open Web Net code you want to execute, e.g. 58#1234## (engage alarm on zones 1,2,3,4)
thanks
can you use code fences in the suggestion? just to be sureâŠ
I read about AUX commands for 3486. In which version is it? I have openhab/testing,now 3.3.0~M4-1 all [installed] but I cannot see it. I get this message:
No ThingHandlerFactory found for thing openwebnet:bus_aux:mhs1:Alarm_activation (thing-type is openwebnet:bus_aux). Deferring initialization.
TY in advance
i have installed the 3.3.0.M5 from oh distribution (in main ui) and i can send aux commands
Mmm⊠that is strange because the contribution that added (initial) AUX support has been accepted days later than M5 has been published.
(That is also why I did not announce that here yet)
Initial AUX support should be included in M6 which will be published at the end of May, I guess.