I have submitted a pull request that fixes the issue of SP2 and SP3 always reporting as OFF. Further I have discovered that some parts of the Broadlink binding has an issue where the devices’ acknowledgment packets sent as a response to a command is not handled - causing different issues for different devices.
In my PR for SP2 and SP3, this problem is solved! It is a very small fix and it should be easy to extend this to other devices as well!
The Power consumption values of SP3s are never read since it is not implemented in the binding yet, but having gotten to understand the binding a bit I might implement this and the Night light switch in the near future.
This is outstanding work @FreddyFox - I’ve approved your PR, merged it and have just published BETA-8 which includes your SP2/SP3 fixes. Thankyou so much for helping with the development of this binding - I don’t (yet*) have an SP- device to test with so your contribution has been really valuable.
I’ve tested the BETA-8 with succes for two SPMini2.
State will be regognised on startup and stay as set.
But PowerConsumption still dosn’t work for Mini Devices.
Many thanks also to @FreddyFox
It’s been a learning experience(never had to edit *.items files as of yet), but i got the binding to work!
i’m on beta7 - didn’t have the time to switch to beta 8, tho there shouldn’t be any difference for the only rm3 ihave.
To anybody whom might be interested:
The codes acquired following this https://github.com/NightRang3r/Broadlink-e-control-db-dump have worked for me so, if you have a rm pro that leads you in the manual to use the IHC app, you can install instead the e-control app (also by broadlink) and follow that guide to aquire the hex codes. The only slippery bit being finding the matching versions of simplejson and python2.7 (doesn’t work with other releases) for your system.
for me, the next thing is discovering how to expose correctly these items to google home now
Anyone who is interested in hooking their Broadlink RM- or SP- device up to Google Home, there a couple of little tricks you may need to employ to get Switchable items to work, so I’ve written up a blog post about it.
It’s working well for me with an RM3 Mini sending IR commands to Daikin and Panasonic airconditioners:
I reckon we go with a completely clean slate - option 2. Then I’ll write one big post to head up the “Next-Gen” topic, with everything up-to-date as of now; installation, discovery, how to store IR codes on IR blaster devices, known issues, etc.
The main feature of this version is support for Dynamic IP Addresses.
There is a new switch available under the advanced Thing properties (open the SHOW MORE area in PaperUI) - it’s marked “Static IP” and it defaults to ON. If you are on a network where your Broadlink device might periodically be issued a different IP address, move it to the OFF position.
Now, if we lose communications with this Thing, rather than mark it OFFLINE, we’ll go into a mini-Discovery mode, and attempt to find the device on the network again, using its MAC address (which never changes).
If we find the device, we update its current IP address in its Thing config, and everything continues without a hiccup. If we fail to find it, it goes OFFLINE as normal.
I should give credit to the LIFX binding which uses a very similar scheme - by chance I happened to come across it and realised it would be great for Broadlink devices too. As an extra bonus, it prompted me to redesign the entire discovery system and make it asynchronous; as a result it is now MUCH more reliable at finding devices (particularly if you have multiple Broadlink devices on your network) without having to scan repeatedly.
I know there have been people in this thread who were looking for this feature - hopefully they can give this a try and give some feedback!