MagicHome LED Strip light controller issue

[RocKKer]

ISY994i v5.0.16c 

Per the "Magic UFO Controller for RGBW" - 

 

I have one RGBW strip light and (I think) a MagicHome controller. I can connect the controller to my WiFI and control from the Android app MagicHome Pro, but can't control via ISY994i using NR. I know I ordered the wrong controller, I need an RGBW controller - but as a proof of concept I'm trying to use it for now. Using NR to send the device any command I get "TCP client read response failed  - net module rule 8". 

 

Here is the controller and the NR configuration and the device IP is correct.

 

 

 

 

 

I must be doing something wrong......

[larryllix]

Which method are you attempting to use? NRs or the NS?

The NRs do not report ant data back and I am not sure you will get any back unless certain modes are turned on.

Have you fixed your IP address for the controller in your router DHCP reservation table and power cycled the controller?

[RocKKer]

I believe I'm using NR, (in the AC, I go to Configuration/Network Resources). 

Is that what the message means, ISY is expecting a response? That's ok if no response, the only response "I" require is that the lights change!  

I just reserved an IP, reset the RGB Controller and power cycled, it got the reserved IP. I made appropriate changes to the NR IP, still not controlling it.

In theory, should the On/Off codes be the same between RGB and RGBW MagicHome controllers? 

[larryllix]

3 hours ago, RocKKer said:

I believe I'm using NR, (in the AC, I go to Configuration/Network Resources). 

Is that what the message means, ISY is expecting a response? That's ok if no response, the only response "I" require is that the lights change!  

I just reserved an IP, reset the RGB Controller and power cycled, it got the reserved IP. I made appropriate changes to the NR IP, still not controlling it.

In theory, should the On/Off codes be the same between RGB and RGBW MagicHome controllers? 

I don't believe the codes are exactly the same. In the packets you have to send as many channels as your controller has. In my controllers they are 5 channel to support R,G,B,WW, & CW.  I do not use the CW, and it was probably discovered it was useless after users owned them for a while. An extra strip of W was not needed as you could mix in some RGB colours and make your own for no extra hardware cost.

In the four channel controllers one byte was eliminated in the channel list packet. I assume anther byte would be eliminated in a 3 channel controller.

These bulb types annd brands are determined by a common protocol request for status send the the bulbs. Of course NRs would not have that luxury as ISY cannot read any intelligent responses and/or parse the response using NRs.

Do you have a RPI or polisy to try the MagicHome NS? It wasn't fancy but IIRC it sorted out the bulb styles and uses the correct packetting.

If you are familiar with python3 I have my NRbridge code if you can make some sense out of to create your NR packets. I used variable substitution to  create custom colours from one NR. I used three in the end. ON, OFF,  & SETLEVELS, for each IP address/bulb. I have since dumped that method and use 3 NRs to send the same but my NRbridge handles the fine details including synchronising bulb groups and animations, and native bulb effects. The flashing is very handy for notifications.

[larryllix]

4 hours ago, RocKKer said:

I believe I'm using NR, (in the AC, I go to Configuration/Network Resources). 

Is that what the message means, ISY is expecting a response? That's ok if no response, the only response "I" require is that the lights change!  

I just reserved an IP, reset the RGB Controller and power cycled, it got the reserved IP. I made appropriate changes to the NR IP, still not controlling it.

In theory, should the On/Off codes be the same between RGB and RGBW MagicHome controllers? 

See post above also.

In the examples in the thread you linked to I will a attempt to demo this from memory.

Red: 49;255;0;0;0;0;15;63;129;138;139;150 <----checksum should remain the same with a deleted 0 = fourth channel

Green: 49;0;255;0;0;0;15;63;129;138;139;150 <----checksum should remain the same with a deleted 0

[RocKKer]

I have a rpi, I'll try the MH NS. 

 

Not sure I want to try the python3 method yet. Thank you for the offer and the info. I have a couple RGBW controllers coming, give them a try when they get here this weekend. 

 

I tried the NR strings you sent me, didn't change the color but I think the green gave a response back to ISY (some sort of characters in the NR resource response window), but I can't replicate.....

[larryllix]

1 hour ago, RocKKer said:

I have a rpi, I'll try the MH NS. 

 

Not sure I want to try the python3 method yet. Thank you for the offer and the info. I have a couple RGBW controllers coming, give them a try when they get here this weekend. 

 

I tried the NR strings you sent me, didn't change the color but I think the green gave a response back to ISY (some sort of characters in the NR resource response window), but I can't replicate.....

For some controllers/bulbs I had to turn the bulb on first before sending colour levels. Others the order didn't matter. Some types cannot have a white command and an RGB colour sent at the same time. Some require a mask to specify which you are sending RGB or White. The wrong sequence, nothing will happen. 

I found an old copy of the hacked API from the linked thread.
 

 

Extend your timeout while experimenting to say... 1200 mSec. If you got some response you are the right track.

MagicHome API.txt

Edited September 16, 2020 by larryllix

[RocKKer]

Thank you larryllix, I got it working with the NS.

Works good enough for now while I figure out what I can control and how to implement. 

 

Another question: 

I want to eventually put these IOT devices (mostly the chinese controllers, not necessarily the ISY and NS) on a separate VLAN. While it's easiest to have all on the same VLAN, are there any suggestions on what devices should be where, I don't really want to create a mountain of firewall rules to keep all working. 

[larryllix]

1 hour ago, RocKKer said:

Thank you larryllix, I got it working with the NS.

Works good enough for now while I figure out what I can control and how to implement. 

 

Another question: 

I want to eventually put these IOT devices (mostly the chinese controllers, not necessarily the ISY and NS) on a separate VLAN. While it's easiest to have all on the same VLAN, are there any suggestions on what devices should be where, I don't really want to create a mountain of firewall rules to keep all working. 

Ithought about that a few years back but it didn't work out for me. One of the most basic things was that WoL can only wake devices on the higher subnet.

hmmmm.. ISY may be able to handle WoL with two subnets.  Have to examine the WoL admin console page. You would need a second DHCP server to handle the second subnet. Most routers don't handle that well.

[RocKKer]

My understanding for WOL, you create the magic packet (using any port) on your source network, at the router you port forward, (changing the port to 9 UDP) to the broadcast address of the destination network. ie: for a 192.168.1.0 network, broadcast would be 192.168.1.255. I've used WOL, but never on a different VLAN (or subnets), so YMMV. 

 

You need to use a router that is not a consumer level router to implement VLANs. I doubt any Asus, Netgear, Linksys, TP-Link, etc. support VLANs. Pro-sumer type routers would (Ubiquiti, PfSense, OpnSense, etc.). I use PfSense and have an IOT VLAN working for my Ecobees and Amazon Echos. I will play around with this after I figure out LED strip lights. 

[larryllix]

On 10/10/2020 at 7:19 AM, MLin said:

it seems milight led controller made by China is very popular in Europe market, have you try it?

I have tried them, own about five bulbs and 20 LED strips controllers. (in a box right now). I was using my own software drivers initiated by ISY NR commands.

MiLight signals are NOT WiFi despite their constant attempts to con buyers. They are 2.4 MHz signals put out by their hubs, controlled by WiFi. You will require a MiLight Hub for every four groups of bulbs (1-4) or LED strip controllers. I was using two Hubs and about to buy a few more when I switched to WiFi based lights and controllers. The MiLight bulbs put out a full range of colours but the RGB LED bulbs were a little weak. The Whites were good brilliance (about 75 W equiv.).

The MiLight LED strip controllers acted exactly the same as the MagicHome controllers, when using the same RGBW LED strips. MiLight protocol is very simple with no feedback to the sender. It takes UDP packets and they are usually sent about three times to increase the chance of success. MagicHome sends TCP packets and can receive confirmations of success, as well as complete status.

IIRC there are 8 group hubs for MiLights now. A group can be any number of bulbs/strips, if your logic can handle that and don't mind a limit of 4 or 8 different colours or levels simultaneously, or using more hubs.

Edited October 12, 2020 by larryllix
Removed spam link. Leaving Larry’s info as it may be useful.

[MrBill]

40 minutes ago, larryllix said:

I have tried them, own about five bulbs and 20 LED strips controllers. (in a box right now). I was using my own software drivers initiated by ISY NR commands.

MiLight signals are NOT WiFi despite their constant attempts to con buyers. They are 2.4 MHz signals put out by their hubs, controlled by WiFi. You will require a MiLight Hub for every four groups of bulbs (1-4) or LED strip controllers. I was using two Hubs and about to buy a few more when I switched to WiFi based lights and controllers. The MiLight bulbs put out a full range of colours but the RGB LEDs were a little weak. The Whites were good brilliance (about 75 W equiv.).

The MiLight LED strip controllers acted exactly the same as the MagicHome controllers, using the same RGBW LEDstrips. MiLight protocol is very simple with no feedback to the sender. It takes UDP packets and they are sent about three times to increase the chance of success. MagicHome sends TCP packets and can receive confirmations of success.

IIRC there are 8 group hubs for MiLights now. A group can be any number of bulbs/strips if your logic can handle that and don;t mind a limit of 4 or 8 different colours or levels, or more hubs.

He succeeded!!.... You quoted all 3 of his link spamming attempts, now he has links and mentions...people are talking about that site!  at least that what search engines think.....

[EKauffman]

On 9/15/2020 at 2:06 PM, RocKKer said:

ISY994i v5.0.16c 

Per the "Magic UFO Controller for RGBW" - 

 

I have one RGBW strip light and (I think) a MagicHome controller. I can connect the controller to my WiFI and control from the Android app MagicHome Pro, but can't control via ISY994i using NR. I know I ordered the wrong controller, I need an RGBW controller - but as a proof of concept I'm trying to use it for now. Using NR to send the device any command I get "TCP client read response failed  - net module rule 8". 

 

Here is the controller and the NR configuration and the device IP is correct.

 

 

 

 

 

I must be doing something wrong......

Looks like you have this figured out now (yes?). I have the same type of controller and I'd like to control it via the 994i. One way is upgrade the RGBW to a z-wave one but if you can do it with this that would be faster and cheaper. Can you walk me through exactly how you did this?

Thanks!!

[RocKKer]

I did get it figured out. I installed Polyglot on a RPi with the Magichome NS. I ordered and received an Magichome RGBW controller and it worked great for both controllers.

Side note: I also moved the ISY and LED controllers to my IOT VLAN. The RPi, which I installed polyglot on, also runs PiHole and DNS, so it stays on the LAN. Once I got the firewall rules configured correctly for the ISY and LED controllers, it all works great! 

[Scottmichaelj]

If possible the Magic Home controllers work best with the Node Server. The other values in the ISY is very crude and basic.