MagicHome Node Server

[fahrer16]

@BIngwell, Short answer is no, not right now.

The node server uses some code developed by some other folks based on reverse engineering the protocol used by the app to send commands to the bulbs, where there are quite a few different "flavors" out there.  That project doesn't include a separate protocol for defining a group; I don't know if that's because the bulbs themselves don't use groups or because it just hasn't been reverse engineering yet.  It's completely possible the app just sends the commands really fast.

On the node server side, it's single-threaded so each individual light is a node and that node receives a command, finishes it, reports it back to the ISY and starts the next command, which slows the process down.  There might be something that could be done to define groups or scenes inside of the node server so that it could send the commands immediately to each bulb without having that lag between them.  I actually don't have have multiple bulbs next to each other so it hasn't been something on my list.

I'm thinking out loud right now but I'm not too familiar with how ISY scenes work with non-insteon nodes behind the scenes.  If the ISY scene were to issue those commands to polyglot simultaneously and polyglot took care of the multi-threaded execution of those commands in parallel it would take care of that issue and be a benefit to all node servers without adding that complexity everywhere.  Or it's also completely possible something like that exists in polyglot already and this node server simply isn't taking advantage of it.

[larryllix]

3 hours ago, fahrer16 said:

@BIngwell, Short answer is no, not right now.

The node server uses some code developed by some other folks based on reverse engineering the protocol used by the app to send commands to the bulbs, where there are quite a few different "flavors" out there.  That project doesn't include a separate protocol for defining a group; I don't know if that's because the bulbs themselves don't use groups or because it just hasn't been reverse engineering yet.  It's completely possible the app just sends the commands really fast.

On the node server side, it's single-threaded so each individual light is a node and that node receives a command, finishes it, reports it back to the ISY and starts the next command, which slows the process down.  There might be something that could be done to define groups or scenes inside of the node server so that it could send the commands immediately to each bulb without having that lag between them.  I actually don't have have multiple bulbs next to each other so it hasn't been something on my list.

I'm thinking out loud right now but I'm not too familiar with how ISY scenes work with non-insteon nodes behind the scenes.  If the ISY scene were to issue those commands to polyglot simultaneously and polyglot took care of the multi-threaded execution of those commands in parallel it would take care of that issue and be a benefit to all node servers without adding that complexity everywhere.  Or it's also completely possible something like that exists in polyglot already and this node server simply isn't taking advantage of it.

My system uses numbers for each bulbs and negative numbers for each grouping. These are defined with constants in ISY integer variables/names to avoid confusion. This means I have to install each bulb IP address and what group each bulb belongs to inside the python3 bridging software code on my polisy or RPi. Not a user friendly method for most ISY people.

 

[sorka]

So I couldn't get the ui to respond at port 3000. Magichome was still working though because the ISY was responding to the level changes I was setting in the magic home app and following the levels just fine although delayed by my few seconds of polling time.

I finally gave up on trying to get the web interface to work. No firewall rules on and the it showed listening on port 3000 from the command line.

 

So I did a:

wget -qO - https://raw.githubusercontent.com/UniversalDevicesInc/polyglot-v2/master/scripts/install.sh | bash -e

 

Which updated everything and now the web UI works fine on port 3000. But magichome shows it's not connected. The ISY is connected. Perhaps the connection to the magichome RGB controller got nuked?

 

 

[sorka]

I went ahead and nuked the magic home node and re-installed from the store. Now it just says "unmanage". So then I delete the node server connection in the ISY and re-added it. No luck. Still says unmanaged in polyglot.

[sorka]

Went ahead and selected uninstall for magichome from the store figuring I'd start all over and it does nothing. I could probably nuke the directory under nodeservers but at this point I'm thinking it's best to wipe polyglot clean off the RPI and start over.

[fahrer16]

@sorka Based on the screenshot you showed with the node server being "disconnected", I'm guessing the config was lost as part of re-installing polyglot since there were no custom configuration parameters shown.  

Sounds like you already went the nuclear route!

[sorka]

I restarted polyglot and tried once more to uninstall magic home. Worked this time. Re-installed and it found the light controller. All working again.

 

Amazing how stuff bitrots when you leave it and do nothing.

[larryllix]

BTW: These bulbs have become very available again on eBay.com eBay.ca amazon.com and some on amazon.ca (very marked up)

Most vendors sell them for about $8 to $12 USD or $10-$18 CAD.
Colours are rich (a little less power, maybe 2W each colour) and whites are very bright especially when WW and CW are both turned on more than 100% total.

The newer style RGBCW can do both WW and CW and it is real CW = not faked RGB mix, so you can get way over 100% brightness out of the new 9W bulb.

Look for the MagicHome app as most of the vendors have no idea what they are selling.

This was the insides of a defective BR-30 bulb that the WW LEDs didn't function. They are quite well built. The defective bulb was replaced with just a photo, proving I had the bulb. Top comes off on a bayonet style mount.

[fahrer16]

The hardware on most of the bulbs and LED strip controllers that use the MagicHome app is actually pretty solid.  Unfortunately, it's pretty limited by the firmware being used with variations in the protocol making consistent operation a challenge.

I've been thinking about flashing my MagicHome controllers with ESPHome firmware, which would allow direct control without the protocol used by the MagicHome app, including have more control over ramps, or effects, etc...  There are a few tutorials out there about flashing the firmware and integrating with home assistant, like this one:
How to install ESPHome on MagicHome LED Controller - Reid Projects (reid-projects.com)

Integrating with Home Assistant is a piece of cake and essentially works out of the box but I generally prefer to have the ISY handle basic things like lighting control that I want to stay reliable.  It's possible to have Home assistant pick up a button press from a keypadlinc and then run an automation to control a light but going through a server for something like that just feels wrong.  Flashing with the ESPHome firmware would also open up the ability for these lights to be controlled over MQTT, so using the MQTT node server might then be an option.

Just some thoughts I've had, but I haven't had the time to try it out.  With how cheap these controllers are though, there's really nothing to lose giving it a shot.

[larryllix]

I now have three different styles of LED strips and bulbs now.
To control anyone of them, the bulb type needs to be interrogated from each device first and depending on what type number you get back, I handle the protocol differently.

Each protocol style varies with must turn the bulb on first, to can set levels before turning the bulb on. Another parameter that varies is dependent on whether the bulb can mix white with the rgb colours, or not. Depending on that factor the rgb and white mask must be set to match the capabilities, or some bulb styles will not function as requested.

A newer addition to the bulbs is dual WW and CW parameters and that must be known before setting levels in the bulbs as the protocol command length includes one more byte to control the extra CW led channel.

I use some of the built in effects to flash bulbs for warnings and take the load off of ISY for that function. I have also created some effects of my own. One rotates the colours and levels around a group of bulbs for a room rotational effect or a sliding colour effect on my more linear arrangement of porch and deck bulbs.

Sent from my SM-G781W using Tapatalk

[brandwidth]

On 6/15/2021 at 11:06 PM, larryllix said:

I now have three different styles of LED strips and bulbs now.
To control anyone of them, the bulb type needs to be interrogated from each device first and depending on what type number you get back, I handle the protocol differently.

Each protocol style varies with must turn the bulb on first, to can set levels before turning the bulb on. Another parameter that varies is dependent on whether the bulb can mix white with the rgb colours, or not. Depending on that factor the rgb and white mask must be set to match the capabilities, or some bulb styles will not function as requested.

A newer addition to the bulbs is dual WW and CW parameters and that must be known before setting levels in the bulbs as the protocol command length includes one more byte to control the extra CW led channel.

I use some of the built in effects to flash bulbs for warnings and take the load off of ISY for that function. I have also created some effects of my own. One rotates the colours and levels around a group of bulbs for a room rotational effect or a sliding colour effect on my more linear arrangement of porch and deck bulbs.

Sent from my SM-G781W using Tapatalk


 

@larryllix - any chance you can share/open source your work? I've not been able to get my LED bulbs to behave consistently - sounds like your approach solves this problem.

[larryllix]

@larryllix - any chance you can share/open source your work? I've not been able to get my LED bulbs to behave consistently - sounds like your approach solves this problem.

Yes. However I have just begun a 21 day holiday in Mexico and will be into Christmas family things for a bit at that time. After that I should have some time to help you through the somewhat technical setup of it.

Sent from my SM-G781W using Tapatalk