themillhousegroup / broadlink-openhab-binding Goto Github PK

Not sure if this is only when multiple Broadlink Things are set up, but it never comes back properly after a restart.

My particular setup is an A1 and RM3 Mini. They work great when freshly-added but after an OpenHAB restart the A1 usually appears as Offline. The RM3 Mini appears Online but doesn't actually seem to work.

This code should have integration tests - it won't be possible to run them in a CI environment, but a developer with a Broadlink device on their network should be able to run them.

Needs to be buildable with Maven

Hello,

in OH 2.3 it worked fine. But not i have no Binding. When will it appear.

Thanks!

The original JAR file will need to be decompiled

The Broadlink devices are identified by their MAC address. The Thing configuration specifies an IP address though, which might change. The code incorrectly uses this IP address when sending datagrams - it shouldn't do this, instead it should look up the current IP address for the given MAC address.

I have a Nexus instance. Until this is production-ready, that should be OK.

This needs unit tests to prove basic elements work correctly

Hello, I have noticed that the latest version of the Broadlink binding (org.openhab.binding.broadlink-3.1.0-SNAPSHOT.jar) is not queuing correctly the sequence of infrared commands.

This issue did not appear in older versions of the binding.

Basically I need to run a sequence of 25-30 IR commands in cascade, to control an older 5.1 speaker system (turn on wifi plug, turn on speaker, change source, then for 5 times in a row increase treble, bass, central, volume 2 times).

Even though I have set a 300-1000 milliseconds timer in the openhab rule between consecutive commands (which did the job in older versions of the binding), now it is behaving abnormally --> IR commands are somehow overlapping and the effective command sequence that is executed in reality is totally unexpected. Some commands are skipped, some are executed more times than requested.

If I run the same sequence with the eschava/broadlink-mqtt daemon (written in python), all commands are queued nicely, regardless of the thread::sleep duration between two consecutive commands - it can be zero!. All commands are nicely queued and executed (even if the rule execution has already ended) and I always get the same results.

rule "big speaker macro ON"
when
        Item v_microlab received command ON
then
logInfo("big speaker macro","Running big speaker macro; command ON; sequence START...")
Sonoff_S26_1.sendCommand(ON)
Thread::sleep(500)
BroadlinkRM2100099_Command.sendCommand("audio_microlab_power")
Thread::sleep(500)
BroadlinkRM2100099_Command.sendCommand("audio_microlab_source")
Thread::sleep(500)
for(var i=1; i<6; i++) {
        logInfo("big speaker macro","===================iteration #" + i)
        BroadlinkRM2100099_Command.sendCommand("audio_microlab_treble_up")
        Thread::sleep(500)
        logInfo("big speaker macro","treble up done")
        BroadlinkRM2100099_Command.sendCommand("audio_microlab_bass_up")
        Thread::sleep(500)
        logInfo("big speaker macro","bass up done")
        BroadlinkRM2100099_Command.sendCommand("audio_microlab_sw_up")
        Thread::sleep(500)
        logInfo("big speaker macro","sw up done")
        BroadlinkRM2100099_Command.sendCommand("audio_microlab_front_up")
        Thread::sleep(500)
        logInfo("big speaker macro","front up done")
        BroadlinkRM2100099_Command.sendCommand("audio_microlab_vol_up")
        Thread::sleep(500)
        logInfo("big speaker macro","vol up done")
        BroadlinkRM2100099_Command.sendCommand("audio_microlab_vol_up")
        Thread::sleep(500)
        logInfo("big speaker macro","vol up 2 done")
}
logInfo("big speaker macro","Running big speaker macro; command ON; sequence END.")
end

Is it possible to implement a fix for this issue?

Thanks in advance