Broadlink / Floureon/Hysen-Thermostat Binding

flo-02-mu · September 14, 2019, 6:40pm

Hi all,

after using some thermostat devices mentioned in Electronic heating thermostat reverse engineering (Beok, Floureon, Decdeal) for quite a while using the python-mqtt bridge, I gave it a try to create a “native” openhab (java) binding without the python-mqtt bridge in between.
Luckily there was already a java api based on the python module available (https://github.com/mob41/broadlink-java-api) so that I just needed to create the openhab part around it.

Code
The code can be found here: https://github.com/flo-02-mu/openhab2-addons/tree/broadlink

Testing
Binary is available here: https://github.com/flo-02-mu/openhab2-addons/releases/download/0.1.7-bl/org.openhab.binding.broadlink-2.5.0-SNAPSHOT.jar

In order to try out the binding, you need to put both, the binding into the addons directory.
Ideally the discovery service finds devices out of the box. If not, debugging output (log:set debug org.openhab.binding.broadlink) would be helpful.

Scope
I personally just own devices labled “Floureon Thermostat”. Apparently they are using broadlink controllers like other devices as well (as shown in the source code of the api). I added support for the “A1 Sensor” without being able to test it. If the binding can support multiple devices, the name broadlink might make sense, if not, renaming the binding to a more specific one could also be an option.

Opinions? Ideas? Success stories?

DennisVonDerBey · September 17, 2019, 10:26pm

I will definitely check this out in the coming days. Thank you!

dastrix80 · September 17, 2019, 10:57pm

I too will set this up in the coming days! Great work

Johannes_Balzer · September 26, 2019, 9:11pm

Awesome Ö_Ö
This is what I’ve been waiting for over a year messing with the stupid python script construction that always fails on me after a few weeks for no apparent reason.
I’ll check it right out

Johannes_Balzer · September 26, 2019, 9:46pm

Just to be clear… this binary you gave us is for Openhab-2.5.0-SNAPSHOT only right?
But when I start up a docker container and put it in my addons folder nothing shows up in paperUI
how is this meant to be used?

dastrix80 · September 27, 2019, 9:56am

No, the binary works just fine in 2.4.0 Stable.

issue a command bundle:list in the karaf console to see the binding

flo-02-mu · September 27, 2019, 10:02am

I did not include any 2.5.0 specifics so it should indeed work with 2.4.0. If you put the two libs in the addons-folder, the binding should install and the auto-discovery should detect the devices right away. If not, it’s time for looking at the logfiles.

Johannes_Balzer · September 27, 2019, 12:26pm

Thanks for your replies,
I’ll check that tonight on the 2.4.0 container.
I’m also going to check the logs and karaf output

Johannes_Balzer · September 27, 2019, 7:25pm

ok so here is the thing.
I currently have 2 files in my addons directory:
broadlink-java-api-1.0.1.jar
org.openhab.binding.broadlink-2.5.0-SNAPSHOT.jar

The openhab.log contains the following output regarding the binding:
2019-09-27 21:11:23.441 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/openhab/addons/org.openhab.binding.broadlink-2.5.0-SNAPSHOT.jar org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.broadlink [206] Unresolved requirement: Import-Package: com.github.mob41.blapi at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?] at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[?:?] at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [10:org.apache.felix.fileinstall:3.6.4] at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [10:org.apache.felix.fileinstall:3.6.4] at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [10:org.apache.felix.fileinstall:3.6.4] at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [10:org.apache.felix.fileinstall:3.6.4] at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [10:org.apache.felix.fileinstall:3.6.4]

So it looks like openhab doesn’t know that the library is in the same folder as the binding I suppose?

Edit:
I also checked in karaf bundle:list
There is no bundle that says anything with broadlink in it.
Also I have cleared /openhab/userdata/cache and /tmp multiple times
Everything to no avail
Edit2:
I even tried a brand new docker container running 2.4.0 with a fresh clean config… same error in the logs.

Johannes_Balzer · September 30, 2019, 4:06pm

Maybe I have to register that API somewhere?
Unfortunately I’m no java dev and can only make some guesses…
Does the openhab engine scan the addons folder for APIs?
If so, I have also tried to rename the JAR file to the name of that API but that didn’t work either.
Or is this whole process handled by this apache directory watcher thing?
Like in this thread:

But then again, I don’t see why this shouldn’t work…
Maybe it is because I’m running all this in a docker environment?

Edit:

I have tried using this binding just to see if putting stuff in the addons folder works.

This one works just fine. However it doesn’t provide all the feature that Florian’s Binding is capable of doing like talking to thermostats and stuff.

flo-02-mu · October 3, 2019, 11:00pm

I can meanwhile reproduce the issue by myself. It seems that I was just lucky to somehow get the broadlink-java-api library installed once, and ever since then the dependency does get resolved.
I have no clue why the installation of the wrapped mvn lib goes wrong I followed the instructions from https://www.openhab.org/docs/developer/buildsystem.html, but with all combinations I tried from the karaf console, all I get is
Unable to install bundle wrap:mvn:com.github.mob41.blapi/broadlink-java-api/1.0.1: org.osgi.framework.BundleException: Error reading bundle content. (tried it with and without meta-data, always the same result.

I will try to build a version the upcoming days with the lib included like described in the documentation as “last resort”, but I am not too happy about that.
@cweitkamp I saw that you updated the documentation about how to handle dependencies with the new build system. Do you have an idea what could go wrong here? The feature file looks as follows:

<?xml version="1.0" encoding="UTF-8"?>
<features name="org.openhab.binding.broadlink-${project.version}" xmlns="http://karaf.apache.org/xmlns/features/v1.4.0">
    <repository>mvn:org.openhab.core.features.karaf/org.openhab.core.features.karaf.openhab-core/${project.version}/xml/features</repository>

    <feature name="openhab-binding-broadlink" description="Broadlink Binding" version="${project.version}">
        <feature>openhab-runtime-base</feature>
        <feature prerequisite="true">wrap</feature>
        <bundle dependency="true">wrap:mvn:com.github.mob41.blapi/broadlink-java-api/1.0.1$Bundle-Name=broadlink-java-api&amp;Bundle-SymbolicName=com.github.mob41.blapi.broadlink-java-api&amp;Bundle-Version=1.0.1</bundle>
        <bundle start-level="80">mvn:org.openhab.addons.bundles/org.openhab.binding.broadlink/${project.version}</bundle>
    </feature>
</features>

Is it in the end some availibility issue on jcenter?

Johannes_Balzer · October 4, 2019, 12:09pm

did you by any chance install that whole maven package on your openhab system?
maybe this way openhab knew that this library was available on your system.

flo-02-mu · October 4, 2019, 12:19pm

For sure I had the maven package lying around, so you might be right.
Anyway: I made a release with the library included in the lib dir. Feel free to try it out from here (note: URL has changed): https://github.com/flo-02-mu/openhab2-addons/releases/download/0.1.0-bl/org.openhab.binding.broadlink-2.5.0-SNAPSHOT.jar

Johannes_Balzer · October 5, 2019, 1:39pm

Than you very much.
This version works as expected.
However it was unable to find my thermostats automatically. I could add them manually and they appear to be “online” in paperUI.
However they get no data.
The log tells me about some exceptions:

2019-10-05 15:33:41.719 [WARN ] [blapi.pkt.cmd.hysen.BaseHysenCommand] - GetBasicInfoCommand received an error: fffffff9 / -7
2019-10-05 15:33:41.720 [ERROR] [al.handler.FloureonThermostatHandler] - Error while retrieving data for broadlink:floureonthermostat:0607c38f
java.lang.NullPointerException: null
at org.openhab.binding.broadlink.internal.handler.FloureonThermostatHandler.refreshData(FloureonThermostatHandler.java:135) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]

and

2019-10-05 15:32:53.543 [ERROR] [al.handler.FloureonThermostatHandler] - Error while retrieving data for broadlink:floureonthermostat:881de954
java.lang.ArrayIndexOutOfBoundsException: 34
at com.github.mob41.blapi.pkt.cmd.hysen.BaseHysenCommand.execute(BaseHysenCommand.java:38) ~[?:?]
at com.github.mob41.blapi.dev.hysen.BaseHysenDevice.getBasicStatus(BaseHysenDevice.java:93) ~[?:?]
at org.openhab.binding.broadlink.internal.handler.FloureonThermostatHandler.refreshData(FloureonThermostatHandler.java:133) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]

Not sure what this is about…

flo-02-mu · October 5, 2019, 2:16pm

@Johannes_Balzer Thank You for the log, now it’s time to start debugging… two questions:

What exact brand name does your thermostat have?
Would you like to debug the discovery? You should already see a line saying “Discovery service found 0 broadlink devices.”, since this is on info level. For more debugging you could go to the openhab console (openhab-cli console) and set:
log:set debug org.openhab.binding.broadlink.
Then rerun the discovery from the GUI.
You should get log entries like:
"Using source address <YOUR_OPENHAB_HOST_IP> for sending out broadcast request."

That part is a bit tricky, since it sends out a broadcast message to the network and specifies to which IP replies should go back. If something goes wrong here (e.g. a loopback IP is used), no devices will be found.

Your current log already shows that:

The authentication with the device succeeded once (otherwise the device would not yet be marked as online
The call for retrieving the actual data is not authenticated anymore. Maybe there are tiny differences between the exact models, but let’s see.

Johannes_Balzer · October 6, 2019, 9:43am

Hi,

sure let’s go.
So I have the classic Floureon Thermostat.
https://www.amazon.de/Beok-WiFi-Raumthermostat-LCD-Touchscreen-Bodensensor-schwarz/dp/B074QJQWTW/ref=sr_1_18?__mk_de_DE=ÅMÅŽÕÑ&keywords=floureon+thermostat&qid=1570354439&sr=8-18
Unfortunately it is an old version because it seems to have been abandoned by most sellers in favour for one of the newer variants.

This is my Log Output when I remove one of three and make it search with your binding:

2019-10-06 11:30:30.495 [DEBUG] [nk.internal.handler.BroadlinkHandler] - Disposing thing broadlink:floureonthermostat:0607c38f
2019-10-06 11:30:30.496 [DEBUG] [nk.internal.handler.BroadlinkHandler] - Thing broadlink:floureonthermostat:0607c38f disposed
2019-10-06 11:30:41.423 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Using source address /192.168.1.19 for sending out broadcast request.
2019-10-06 11:31:11.448 [INFO ] [.discovery.BroadlinkDiscoveryService] - Discovery service found 2 broadlink devices.
2019-10-06 11:31:11.449 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Broadlink device Floureon Thermostat of type ffffffad with Host 192.168.1.102 and MAC 34:ea:34:7b:64:23
2019-10-06 11:31:11.449 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Device ID with IP address replacement: 192-168-1-102
2019-10-06 11:31:11.458 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Device ID with DNS name: 192
2019-10-06 11:31:11.459 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Property map: {host=192.168.1.102, description=Floureon Thermostat, mac=34:ea:34:7b:64:23}
2019-10-06 11:31:11.460 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘broadlink:floureonthermostat:192’ to inbox.
2019-10-06 11:31:11.461 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Broadlink device Floureon Thermostat of type ffffffad with Host 192.168.1.100 and MAC 34:ea:34:77:94:cd
2019-10-06 11:31:11.461 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Device ID with IP address replacement: 192-168-1-100
2019-10-06 11:31:11.471 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Device ID with DNS name: 192
2019-10-06 11:31:11.471 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Property map: {host=192.168.1.100, description=Floureon Thermostat, mac=34:ea:34:77:94:cd}
2019-10-06 11:31:28.059 [WARN ] [blapi.pkt.cmd.hysen.BaseHysenCommand] - GetBasicInfoCommand received an error: fffffff9 / -7
2019-10-06 11:31:28.059 [DEBUG] [al.handler.FloureonThermostatHandler] - Retrieved data from device broadlink:floureonthermostat:7b329945: null
2019-10-06 11:31:28.059 [ERROR] [al.handler.FloureonThermostatHandler] - Error while retrieving data for broadlink:floureonthermostat:7b329945
java.lang.NullPointerException: null
at org.openhab.binding.broadlink.internal.handler.FloureonThermostatHandler.refreshData(FloureonThermostatHandler.java:135) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
2019-10-06 11:31:36.719 [ERROR] [al.handler.FloureonThermostatHandler] - Error while retrieving data for broadlink:floureonthermostat:881de954
java.lang.ArrayIndexOutOfBoundsException: 34
at com.github.mob41.blapi.pkt.cmd.hysen.BaseHysenCommand.execute(BaseHysenCommand.java:38) ~[?:?]
at com.github.mob41.blapi.dev.hysen.BaseHysenDevice.getBasicStatus(BaseHysenDevice.java:93) ~[?:?]
at org.openhab.binding.broadlink.internal.handler.FloureonThermostatHandler.refreshData(FloureonThermostatHandler.java:133) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
2019-10-06 11:32:02.692 [DEBUG] [nk.internal.handler.BroadlinkHandler] - Config properties: Configuration[{key=host; type=String; value=192.168.1.100}, {key=mac; type=String; value=34:ea:34:77:94:cd}]
2019-10-06 11:32:02.692 [DEBUG] [nk.internal.handler.BroadlinkHandler] - host: 192.168.1.100, mac: 34:ea:34:77:94:cd, deviceDescription: Floureon Thermostat
2019-10-06 11:32:02.715 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler FloureonThermostatHandler tried updating the thing status although the handler was already disposed.
2019-10-06 11:32:02.717 [WARN ] [.core.thing.binding.BaseThingHandler] - BaseThingHandler.initialize() will be removed soon, ThingStatus can be set manually via updateStatus(ThingStatus.ONLINE)
2019-10-06 11:32:02.865 [DEBUG] [al.handler.FloureonThermostatHandler] - Retrieved data from device broadlink:floureonthermostat:192: BaseStatusInfo [
remote lock=false,
power=true,
active=false,
manual temp=false,
room temp=23.0,
thermostat temp=15.0,
auto_mode=false,
loop_mode=D12345_67,
sensor=INTERNAL,
osv=42,
dif=2,
svh=35,
svl=5,
room_temp_adj=-130.0,
anti freeze=SHUT_DOWN,
powerOnMemory=ON_NO_NEED_MEM,
fac?=0,
external temp=0.0]
2019-10-06 11:32:02.865 [DEBUG] [al.handler.FloureonThermostatHandler] - Updating channel roomtemperature with value 23.0
2019-10-06 11:32:02.865 [DEBUG] [al.handler.FloureonThermostatHandler] - Mode manual

So It seems like it also returns some valid data now.
I have removed the remaining manually added thermostats and added them via a search with your binding.
Which works fine with just one thermostat, but not so much when searching for three.

2019-10-06 11:38:24.499 [DEBUG] [nk.internal.handler.BroadlinkHandler] - Disposing thing broadlink:floureonthermostat:7b329945
2019-10-06 11:38:24.499 [DEBUG] [nk.internal.handler.BroadlinkHandler] - Thing broadlink:floureonthermostat:7b329945 disposed
2019-10-06 11:38:27.135 [DEBUG] [nk.internal.handler.BroadlinkHandler] - Disposing thing broadlink:floureonthermostat:881de954
2019-10-06 11:38:27.135 [DEBUG] [nk.internal.handler.BroadlinkHandler] - Thing broadlink:floureonthermostat:881de954 disposed
2019-10-06 11:38:31.023 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Using source address /192.168.1.19 for sending out broadcast request.
2019-10-06 11:39:01.055 [INFO ] [.discovery.BroadlinkDiscoveryService] - Discovery service found 2 broadlink devices.
2019-10-06 11:39:01.055 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Broadlink device Floureon Thermostat of type ffffffad with Host 192.168.1.100 and MAC 34:ea:34:77:94:cd
2019-10-06 11:39:01.055 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Device ID with IP address replacement: 192-168-1-100
2019-10-06 11:39:01.064 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Device ID with DNS name: 192
2019-10-06 11:39:01.064 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Property map: {host=192.168.1.100, description=Floureon Thermostat, mac=34:ea:34:77:94:cd}
2019-10-06 11:39:01.065 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Broadlink device Floureon Thermostat of type ffffffad with Host 192.168.1.101 and MAC 34:ea:34:70:5b:4c
2019-10-06 11:39:01.065 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Device ID with IP address replacement: 192-168-1-101
2019-10-06 11:39:01.074 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Device ID with DNS name: 192
2019-10-06 11:39:01.074 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Property map: {host=192.168.1.101, description=Floureon Thermostat, mac=34:ea:34:70:5b:4c}
2019-10-06 11:39:01.075 [DEBUG] [nk.internal.handler.BroadlinkHandler] - Disposing thing broadlink:floureonthermostat:192
2019-10-06 11:39:01.075 [DEBUG] [nk.internal.handler.BroadlinkHandler] - Thing broadlink:floureonthermostat:192 disposed
2019-10-06 11:39:01.075 [WARN ] [.core.thing.binding.BaseThingHandler] - BaseThingHandler.initialize() will be removed soon, ThingStatus can be set manually via updateStatus(ThingStatus.ONLINE)
2019-10-06 11:39:42.292 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Using source address /192.168.1.19 for sending out broadcast request.
2019-10-06 11:40:12.328 [INFO ] [.discovery.BroadlinkDiscoveryService] - Discovery service found 2 broadlink devices.
2019-10-06 11:40:12.329 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Broadlink device Floureon Thermostat of type ffffffad with Host 192.168.1.102 and MAC 34:ea:34:7b:64:23
2019-10-06 11:40:12.329 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Device ID with IP address replacement: 192-168-1-102
2019-10-06 11:40:12.338 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Device ID with DNS name: 192
2019-10-06 11:40:12.339 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Property map: {host=192.168.1.102, description=Floureon Thermostat, mac=34:ea:34:7b:64:23}
2019-10-06 11:40:12.340 [DEBUG] [nk.internal.handler.BroadlinkHandler] - Disposing thing broadlink:floureonthermostat:192
2019-10-06 11:40:12.341 [DEBUG] [nk.internal.handler.BroadlinkHandler] - Thing broadlink:floureonthermostat:192 disposed
2019-10-06 11:40:12.341 [WARN ] [.core.thing.binding.BaseThingHandler] - BaseThingHandler.initialize() will be removed soon, ThingStatus can be set manually via updateStatus(ThingStatus.ONLINE)
2019-10-06 11:40:12.341 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Broadlink device Floureon Thermostat of type ffffffad with Host 192.168.1.100 and MAC 34:ea:34:77:94:cd
2019-10-06 11:40:12.341 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Device ID with IP address replacement: 192-168-1-100
2019-10-06 11:40:12.351 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Device ID with DNS name: 192
2019-10-06 11:40:12.351 [DEBUG] [.discovery.BroadlinkDiscoveryService] - Property map: {host=192.168.1.100, description=Floureon Thermostat, mac=34:ea:34:77:94:cd}
2019-10-06 11:40:12.352 [DEBUG] [nk.internal.handler.BroadlinkHandler] - Disposing thing broadlink:floureonthermostat:192
2019-10-06 11:40:12.352 [DEBUG] [nk.internal.handler.BroadlinkHandler] - Thing broadlink:floureonthermostat:192 disposed
2019-10-06 11:40:12.353 [WARN ] [.core.thing.binding.BaseThingHandler] - BaseThingHandler.initialize() will be removed soon, ThingStatus can be set manually via updateStatus(ThingStatus.ONLINE)

It seems like the binding thinks their DNS name is all the same and can’t determine which one is a new one so it discovers them, but afterwards drops them.

Edit:
Ooooh it sets the device ID by the DNS name and since the binding thinks all the devices DNS name is the first octet of their IP it tries to use the same for all of them, which won’t work.
But I’m not sure how the plugin thinks the IP is the DNS name, because I set their hostnames to “Thermos1” “Thermos2” and “Thermos3” in openwrt.

Edit2:
Also I noticed that it only refreshed the states of the newly added item just once and then I found the log-entry at about 11:56 where it stated “Mode manual”.
After that nothing happened.

flo-02-mu · October 6, 2019, 12:17pm

Yes, this is exactly what goes wrong here. Unfortunately, I cannot retrieve some sort of ID from the device, that’s why I wanted to use the announced DNS name (like in your case: Thermos1).
If you don’t overwrite them, they look like this:
broadlink-oem-t1-7a-8b-24.your.domain, and I wanted to use the first part. If it is a different pattern, it goes wrong…

I uploaded a new version which checks for a regex. If it does not match, it simply returns the original hostname (could still be an IP adress though). If this still does not work, I might probably just use the MAC address, to be on the safe side… but let’s see:

https://github.com/flo-02-mu/openhab2-addons/releases/download/0.1.1-bl/org.openhab.binding.broadlink-2.5.0-SNAPSHOT.jar

(You need to remove the devices and rerun a new discovery)

Johannes_Balzer · October 6, 2019, 6:08pm

I have nothing to add here, works like a charm

Edit: Although I think using the Mac-Address would be a nice touch for People who didn’t set up their DNS properly, like I did forget about in my docker container, because I always forget about that

Edit2:
I noticed that it is still not updating the values on the channels.
It does it about 1 or 2 times and then nothing in the openhab.log.
It says Updating Channel roomtemperature with value 20.5 about one or two times and then stops outputting.
Maybe do I have to set a refresh interval or is that done by openhab itself?

Edit 3:
Ok, nevermind it updated again… not sure why but it seems to do it now.

flo-02-mu · October 6, 2019, 8:53pm

It should actually refresh every thermostat every minute. Is there really nothing suspicious in the log anymore? I would either expect an entry saying Error while retrieving data for ... or something about disposal of the thing (which would stop the refresh scheduler).

Johannes_Balzer · October 6, 2019, 8:59pm

This is the whole log output for the last 1.5 hours:

2019-10-06 20:46:33.726 [DEBUG] [al.handler.FloureonThermostatHandler] - Updating channel roomtemperature with value 20.5
2019-10-06 20:46:33.726 [DEBUG] [al.handler.FloureonThermostatHandler] - Mode manual
2019-10-06 20:46:34.441 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model ‘default.items’
2019-10-06 20:46:34.972 [DEBUG] [al.handler.FloureonThermostatHandler] - Retrieved data from device broadlink:floureonthermostat:Thermos3: BaseStatusInfo [
remote lock=false,
power=true,
active=false,
manual temp=false,
room temp=20.5,
thermostat temp=15.0,
auto_mode=false,
loop_mode=D12345_67,
sensor=INTERNAL,
osv=42,
dif=2,
svh=35,
svl=5,
room_temp_adj=-131.0,
anti freeze=SHUT_DOWN,
powerOnMemory=ON_NO_NEED_MEM,
fac?=0,
external temp=0.0]
2019-10-06 20:46:34.973 [DEBUG] [al.handler.FloureonThermostatHandler] - Updating channel roomtemperature with value 20.5
2019-10-06 20:46:34.973 [DEBUG] [al.handler.FloureonThermostatHandler] - Mode manual
2019-10-06 21:27:57.768 [INFO ] [ui.habmin.internal.servlet.HABminApp] - Started HABmin servlet at /habmin
2019-10-06 22:43:17.800 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model ‘default.items’
2019-10-06 22:43:17.832 [DEBUG] [al.handler.FloureonThermostatHandler] - Command class: class org.eclipse.smarthome.core.types.RefreshType
2019-10-06 22:43:17.832 [DEBUG] [al.handler.FloureonThermostatHandler] - Command class: class org.eclipse.smarthome.core.types.RefreshType
2019-10-06 22:43:17.833 [DEBUG] [al.handler.FloureonThermostatHandler] - Command: REFRESH
2019-10-06 22:43:17.835 [DEBUG] [al.handler.FloureonThermostatHandler] - Command class: class org.eclipse.smarthome.core.types.RefreshType
2019-10-06 22:43:17.835 [DEBUG] [al.handler.FloureonThermostatHandler] - Command: REFRESH
2019-10-06 22:43:17.835 [DEBUG] [al.handler.FloureonThermostatHandler] - Command class: class org.eclipse.smarthome.core.types.RefreshType
2019-10-06 22:43:17.837 [DEBUG] [al.handler.FloureonThermostatHandler] - Command: REFRESH
2019-10-06 22:43:17.831 [DEBUG] [al.handler.FloureonThermostatHandler] - Command class: class org.eclipse.smarthome.core.types.RefreshType
2019-10-06 22:43:17.838 [DEBUG] [al.handler.FloureonThermostatHandler] - Command: REFRESH
2019-10-06 22:43:17.838 [DEBUG] [al.handler.FloureonThermostatHandler] - Command: REFRESH
2019-10-06 22:43:18.022 [DEBUG] [al.handler.FloureonThermostatHandler] - Retrieved data from device broadlink:floureonthermostat:Thermos3: BaseStatusInfo [
remote lock=false,
power=true,
active=false,
manual temp=false,
room temp=21.5,
thermostat temp=15.0,
auto_mode=false,
loop_mode=D12345_67,
sensor=INTERNAL,
osv=42,
dif=2,
svh=35,
svl=5,
room_temp_adj=-131.0,
anti freeze=SHUT_DOWN,
powerOnMemory=ON_NO_NEED_MEM,
fac?=0,
external temp=0.0]
2019-10-06 22:43:18.023 [DEBUG] [al.handler.FloureonThermostatHandler] - Updating channel roomtemperature with value 21.5
2019-10-06 22:43:18.023 [DEBUG] [al.handler.FloureonThermostatHandler] - Mode manual
2019-10-06 22:43:18.163 [DEBUG] [al.handler.FloureonThermostatHandler] - Retrieved data from device broadlink:floureonthermostat:Thermos3: BaseStatusInfo [
remote lock=false,
power=true,
active=false,
manual temp=false,
room temp=21.5,
thermostat temp=15.0,
auto_mode=false,
loop_mode=D12345_67,
sensor=INTERNAL,
osv=42,
dif=2,
svh=35,
svl=5,
room_temp_adj=-131.0,
anti freeze=SHUT_DOWN,
powerOnMemory=ON_NO_NEED_MEM,
fac?=0,
external temp=0.0]
2019-10-06 22:43:18.164 [DEBUG] [al.handler.FloureonThermostatHandler] - Updating channel roomtemperature with value 21.5
2019-10-06 22:43:18.164 [DEBUG] [al.handler.FloureonThermostatHandler] - Mode manual
2019-10-06 22:43:18.308 [DEBUG] [al.handler.FloureonThermostatHandler] - Retrieved data from device broadlink:floureonthermostat:Thermos3: BaseStatusInfo [
remote lock=false,
power=true,
active=false,
manual temp=false,
room temp=21.5,
thermostat temp=15.0,
auto_mode=false,
loop_mode=D12345_67,
sensor=INTERNAL,
osv=42,
dif=2,
svh=35,
svl=5,
room_temp_adj=-131.0,
anti freeze=SHUT_DOWN,
powerOnMemory=ON_NO_NEED_MEM,
fac?=0,
external temp=0.0]
2019-10-06 22:43:18.309 [DEBUG] [al.handler.FloureonThermostatHandler] - Updating channel roomtemperature with value 21.5
2019-10-06 22:43:18.309 [DEBUG] [al.handler.FloureonThermostatHandler] - Mode manual
2019-10-06 22:43:18.446 [DEBUG] [al.handler.FloureonThermostatHandler] - Retrieved data from device broadlink:floureonthermostat:Thermos3: BaseStatusInfo [
remote lock=false,
power=true,
active=false,
manual temp=false,
room temp=21.5,
thermostat temp=15.0,
auto_mode=false,
loop_mode=D12345_67,
sensor=INTERNAL,
osv=42,
dif=2,
svh=35,
svl=5,
room_temp_adj=-131.0,
anti freeze=SHUT_DOWN,
powerOnMemory=ON_NO_NEED_MEM,
fac?=0,
external temp=0.0]
2019-10-06 22:43:18.446 [DEBUG] [al.handler.FloureonThermostatHandler] - Updating channel roomtemperature with value 21.5
2019-10-06 22:43:18.446 [DEBUG] [al.handler.FloureonThermostatHandler] - Mode manual
2019-10-06 22:43:18.596 [DEBUG] [al.handler.FloureonThermostatHandler] - Retrieved data from device broadlink:floureonthermostat:Thermos3: BaseStatusInfo [
remote lock=false,
power=true,
active=false,
manual temp=false,
room temp=21.5,
thermostat temp=15.0,
auto_mode=false,
loop_mode=D12345_67,
sensor=INTERNAL,
osv=42,
dif=2,
svh=35,
svl=5,
room_temp_adj=-131.0,
anti freeze=SHUT_DOWN,
powerOnMemory=ON_NO_NEED_MEM,
fac?=0,
external temp=0.0]
2019-10-06 22:43:18.597 [DEBUG] [al.handler.FloureonThermostatHandler] - Updating channel roomtemperature with value 21.5
2019-10-06 22:43:18.597 [DEBUG] [al.handler.FloureonThermostatHandler] - Mode manual
2019-10-06 22:47:18.474 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model ‘default.sitemap’
2019-10-06 22:51:35.003 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘chromecast:chromecast:28c83c7520a5bff152dc6a706f77f004’ to inbox.
2019-10-06 22:55:05.289 [DEBUG] [al.handler.FloureonThermostatHandler] - Command class: class org.eclipse.smarthome.core.library.types.OnOffType
2019-10-06 22:55:05.290 [DEBUG] [al.handler.FloureonThermostatHandler] - Command: ON
2019-10-06 22:55:05.290 [WARN ] [al.handler.FloureonThermostatHandler] - Channel broadlink:floureonthermostat:Thermos3:active does not support command ON

So It basically updated after 1:15 hours for about 5 times at an interval of 10 times per second, and then stopped updating