No announcement yet.

Magic Home Plugin - Support for addressable RGB controller

  • Filter
  • Time
  • Show
Clear All
new posts

    I don't understand why I am not having success with flashing ESP8266, but I did have it with ESP32. It really does not matter which is used for integration with HS as long as flashing is possible. I will look more later for the ESP8266, but for now I just want to document the integration with HS.

    1. Flash WLED. Last release is 8.5. I am actually using beta 2 of 9 that I compiled from source from github. I suggest just using the binary that was already compiled.
    2. Configure WLED for your network. The device will setup an AP on using SSID starting with WLED. Search google for setup if not obvious. I skipped this step because I compiled my network credentials in the source build.
    2. Install mcsMQTT from HS Updater.
    3. Go to IP of ESP (e.g. in my case) and select the Sync Interfaces button. Toward the bottom of the page will be the MQTT setup shown below. Two entries to be made. Enable MQTT checkbox and the IP address of the HS Server. mcsMQTT will be the broker running on the same IP, but port 1883 rather than the HS server on port 80.

    No change needed, but note the Device Topic. It will be showing up in mcsMQTT.

    Click image for larger version  Name:	WLED_MQTT.PNG Views:	0 Size:	21.0 KB ID:	1357701
    4. Restart ESP to start MQTT running on it.
    5. Access mcsMQTT from HS plugins menu item. On Association tab of mcMQTT the current state of WLED configuration will appear as shown below

    Click image for larger version  Name:	Capture.PNG Views:	0 Size:	68.5 KB ID:	1357702
    The topic wled/55b1f4/g is the brightness reported. wled/551f4/c is the color. You will not see the first line shown above because I sent that from another computer to change the brightness of the WLED.

    Working on brightness first select the "a" column checkbox to create a HS device for managing brightness. The "ref" column box will change to a pushbutton with the HS Device Reference and the "TOPIC" column for that row will show an additional text box for the command topic to be used to change the brightness. Fill in the same topic showing on the Sub: line, but leave off the "/g". This is the topic per the WLED API to use to control brightness.

    Click image for larger version  Name:	Capture1.PNG Views:	0 Size:	8.9 KB ID:	1357703
    HS wil now have a number box setup to specify the brightness. In the current version of mcsMQTT a slider is available, but the version in the updater does not have it. We can change this later, but for now this will suffice.

    Next is the color that shows as #FFA000 in my case. Click on the "a" checkbox to create the HS device, In the new textbox in TOPIC column enter the same topic as Sub: line, but suffix "ol" as /col is the end point per WLED API to command color.

    Click image for larger version  Name:	Capture2.PNG Views:	0 Size:	9.2 KB ID:	1357704

    Since the payload looks like text to mcsMQTT it will setup a text box entry in HS device. This is not what we want, but want a color picker. Click on the Ref bottom of the row (1761 above) to bring up the popup to change it to RGB color picker. Note the Control Status UI row where this is done. The RGB radio is selected and now the HS device will show a color picker control on Device Management.

    Click image for larger version  Name:	Capture3.PNG Views:	0 Size:	18.4 KB ID:	1357705

    The next thing of interest is the effects selector. Apparently WLED does not report the status showing which effect is active. That is something that seems like an appropriate enhancement to be made. I probably could add it to the source, but should be something done by the author. Not needed, but positive feedback is always nice to have so HS remains in sync.

    To cover this we will make up a topic just as a placeholder to have a device to put the effects selection. Refresh mcsMQTT page to get a fresh page that will have an empty Edit/Add tab

    Click image for larger version  Name:	Capture5.PNG Views:	0 Size:	11.5 KB ID:	1357706
    In the Sub: text box enter the dummy topic. I used wled/55bf14/fx. mcsMQTT then creates a new device. In this case it is 1762. Effects are commanded per topic wled/55bf14/api per WLED API. The commands supported via this topic are disclosed at This means that the HS Device Publish Topic is set to wled/55bf14/api

    There are a few ways to go with using this newly created device. In the simplest case it will be for the LED Effect index for WLED which has a value between 0 and 79. The easiest setup is create a number box on HS device where one types the desired number. Another is to setup Value-Status pairs and then a list pulldown or set of buttons. While still on the edit/add tab of newly created device select the Control/Status UI to be number for the first case or List/Button for the second case. For right now let us use the number box. It can be changed later. When Button or List is selected then the row HS Device VSP List is populated with a text box to allow entry or value-status pairs.

    The WLED API indicates that the payload needs to be prefixed with a parameter. LED Effect Index uses "&FX". This means that the Publish Payload Template line on the Edit/Add tab for this device needs to have "&FX=" followed by $$VALUE: where $$VALUE: is the substitution variable for the HS Device value. The result of this is shown below.

    Click image for larger version

Name:	Capture6.PNG
Views:	193
Size:	83.5 KB
ID:	1357708

    I still need to proof this, but running out of time now. There are other options for configuration such as creating other devices that use the /api topic for speed (SX=), effect intensity (IX=), etc from the WLED API reference.


      Now that I understand wled API what I will do is add it to mcsMQTT. Anytime a topic starting with wled is observed it will setup everything in HS just as outlined in the step by step procedure. I will use VSP for preset and other similar options to provide a preset type operation.


        Originally posted by Michael McSharry View Post
        Now that I understand wled API what I will do is add it to mcsMQTT. Anytime a topic starting with wled is observed it will setup everything in HS just as outlined in the step by step procedure. I will use VSP for preset and other similar options to provide a preset type operation.
        Thank you Michael, Getting this working will be a milestone for me and HS but This will give me the ability to really customize my lights and the flexibility to create some wanted events, and adding this to my Magiclights and Tuya in HS4 should keep me busy


          Originally posted by Michael McSharry View Post
          Now that I understand wled API what I will do is add it to mcsMQTT. Anytime a topic starting with wled is observed it will setup everything in HS just as outlined in the step by step procedure. I will use VSP for preset and other similar options to provide a preset type operation.
          Thank you very much! So just to make sure I understand, after you make the changes to the plugin, will the above steps still need to be done or will the plugin automatically perform those steps?

          Sent from my iPad using Tapatalk
          HS4 &HSTouch Designer 3.0.80
          BLBackup, BLOccupied, BLShutdown, EasyTrigger, Ecobee, Nest, AK Bond
          EnvisaLink DSC, PHLocation, Pushover, SONOS, Blue Iris, UltraRachio3,
          weatherXML, Jon00 Alexa Helper, Network Monitor, MyQ, Z-Wave


            The plugin is doing it all now when is see a topic starting with wled/. What I have implemented is the online status device, on/off buttons, brightness slider, Color picker, Effect selector with all available effects which I think are 73. A slider for Effect speed and a slider for Effect intensity. There are a number of ofther end points that I set everything up, but did not create the HS device. These just need the "a" column checkbox checked and everything else happens automatically. Examples are nighttime, modes and about a dozen others that are reported on the /api topic. I did discover the /api topic does report the current effect so there is feedback to use fo sync the HS device. I will post it later today. It will be an update to mcsMQTT so the first step is to install mcsMQTT and then copy two files that contain the update.


              I moved the continued discussion of mcsMQTT integration of WLED to

              It should be clear that while the MagicHome hardware can support the WLED firmware, the MagicHome App does not so unless changes are made to the MagicHome plugin then the integration described here cannot be done with MagicHome plugin.

              It should also be pointed out that the stock MagicHome firmware does not run WLED so this hardware will need to be flashed with different firmware. There are many descriptions and videos on doing this flashing.


                Hi Micheal,

                I tired your plugin again.

                When the plugin does not run, the cpu time (% use over time is at 1.4-1.5%) for the hsconsole.exe process .

                but when i start your plugin , change the broker to my personal one, and let it run, the %cpu (devised by the time since the app is running) , is at 4.5-5%.

                Do you know what could cause this?


                  The default setup for mcsMQTT is to listen to everything that is routed through the broker. This is great when you want to setup a new widget to be part of HS, but if there is a lot of MQTT traffic that is not of interest then it is just a waste of CPU cycles. After you have your setup configured then change the General tab setting in Inbound Management to only listen to what you have associated to HS devices. You can always change it back later if you want to discover something else that was recently added to MQTT network.

                  There is a section of the manual on Performance considerations and it contains some benchmarking that determined the main culprit for CPU use is when the HS object needs to be used. This means that if you associate many end points to HS devices then there is processing burden. Express mode was setup to help address this. Again look at the benchmarks. There is some loss of extended capability in Express mode but for most things it will do what you want. Express mode is selected on topic by topic basis so you can use normal mode for topics that need extended processing. There is also some configuration options on General tab, Inbound management as to which feature should be enabled in Express mode.

                  At startup, mcsMQTT can enumerate all HS devices so any device is available for selection on Association tab to be mapped to MQTT topics. The default had been to always do it at startup. I have changed the default to only do it when requested. The only time you want to enumerate the devices is if you added a new one that you want to be used with MQTT. Look at the General tab, Outbound management, HS Device Discovery setting at the bottom to see how your mcsMQTT.ini has it setup.