Homeseer HSM200 Zwave LED On/Off and Color Control

Configuration Z-Wave
7

Well you have the best case scenario. All you should have to do is modify the discovery schema to allow “notification sensor” device types to have lights.

const.DISC_COMPONENT: "light",
        const.DISC_GENERIC_DEVICE_CLASS: [
            const.GENERIC_TYPE_SWITCH_MULTILEVEL,
            const.GENERIC_TYPE_SWITCH_REMOTE,
            const.GENERIC_TYPE_SENSOR_NOTIFICATION,
        ],
        const.DISC_SPECIFIC_DEVICE_CLASS: [
            const.SPECIFIC_TYPE_POWER_SWITCH_MULTILEVEL,
            const.SPECIFIC_TYPE_SCENE_SWITCH_MULTILEVEL,
            const.SPECIFIC_TYPE_NOT_USED,
            const.SPECIFIC_TYPE_NOTIFICATION_SENSOR,
        ],

You should then get a light entity with a color wheel to set the RGB values.

You can download the existing zwave component and install it as a custom component (copy all files to <config_dir>/custom_components/zwave.

Otherwise, you could submit an issue to HA. It’s unlikely anyone will update the zwave integration for you. Probably someone would update the ozw integration but you’d need to submit an MQTT dump.

8

That’s better than I expected. I have no issues with generating and maintaining a custom component for a deprecated (or at least, on its way out) feature. If it works, what are the odds of a pull request being accepted? I’d be willing to go through the hassle if ozw is far enough out that someone else might benefit.

I’ll update once I get a chance to test. I’m assuming I need to remove the node and reattach it, not just restart?

9

I think they might accept a PR, but I can’t say for sure.

You shouldn’t need to remove the node, just restart HA after the component is added.

10

I did this, restarted HA, and indeed a light entity is created. There may be more modifications required, no matter what I put into the light.turn_on service data it seems to send color “#ff00000000” when the device wants #ff0000 or “Red” for example. Here is what is sent (doesn’t actually turn the light on):

2020-09-01 11:35:17.102 Info, Node028, Value::Set - COMMAND_CLASS_COLOR - Color - 0 - 1 - #ff00000000
2020-09-01 11:35:17.103 Info, Node028, Color::SetValue - Setting Color value
2020-09-01 11:35:17.103 Detail, Node028, Queuing (Send) ColorCmd_Set (Node=28): 0x01, 0x14, 0x00, 0x13, 0x1c, 0x0d, 0x33, 0x05, 0x05, 0x02, 0xff, 0x03, 0x00, 0x04, 0x00, 0x00, 0x00, 0x01, 0x00, 0x25, 0xf8, 0xfc
2020-09-01 11:35:17.103 Detail, Node028, Queuing (Send) ColorCmd_Get (Node=28): 0x01, 0x0a, 0x00, 0x13, 0x1c, 0x03, 0x33, 0x03, 0x02, 0x25, 0xf9, 0x17
2020-09-01 11:35:17.104 Detail, Node028, Queuing (Send) ColorCmd_Get (Node=28): 0x01, 0x0a, 0x00, 0x13, 0x1c, 0x03, 0x33, 0x03, 0x03, 0x25, 0xfa, 0x15
2020-09-01 11:35:17.104 Detail, Node028, Queuing (Send) ColorCmd_Get (Node=28): 0x01, 0x0a, 0x00, 0x13, 0x1c, 0x03, 0x33, 0x03, 0x04, 0x25, 0xfb, 0x13

which is followed with a series of Gets, one of which is:

2020-09-01 11:35:17.269 Info, Node028, Response RTT 41 Average Response RTT 40
2020-09-01 11:35:17.269 Info, Node028, Received a updated Color from Device: #000000
2020-09-01 11:35:17.269 Detail, Node028, Refreshed Value: old value=#000000, new value=#000000, type=string
2020-09-01 11:35:17.269 Detail, Node028, Changes to this value are not verified
2020-09-01 11:35:17.269 Detail, Node028, Refreshed Value: old value=0, new value=0, type=list
2020-09-01 11:35:17.269 Detail, Node028, Changes to this value are not verified
2020-09-01 11:35:17.269 Detail, Node028,   Expected reply and command class was received
2020-09-01 11:35:17.269 Detail, Node028,   Message transaction complete

From the first link in my original post, there is a sequence that works (that poster was using the OpenZwave Control Panel to test):

2018-05-30 21:59:16.681 Info, Node041, Value::Set - COMMAND_CLASS_COLOR -  - 1 - 1 - Red
2018-05-30 21:59:16.682 Info, Node041, Color::SetValue - Setting Color Index Value (Fake)
2018-05-30 21:59:16.682 Detail, Node041, Queuing (Send) ColorCmd_Set (Node=41): 0x01, 0x10, 0x00, 0x13, 0x29, 0x09, 0x33, 0x05, 0x03, 0x02, 0xff, 0x03, 0x00, 0x04, 0x00, 0x25, 0xaf, 0x99
2018-05-30 21:59:16.683 Detail, Node041, Queuing (Send) ColorCmd_Get (Node=41): 0x01, 0x0a, 0x00, 0x13, 0x29, 0x03, 0x33, 0x03, 0x02, 0x25, 0xb0, 0x6b
2018-05-30 21:59:16.683 Detail, Node041, Queuing (Send) ColorCmd_Get (Node=41): 0x01, 0x0a, 0x00, 0x13, 0x29, 0x03, 0x33, 0x03, 0x03, 0x25, 0xb1, 0x6b
2018-05-30 21:59:16.683 Detail, Node041, Queuing (Send) ColorCmd_Get (Node=41): 0x01, 0x0a, 0x00, 0x13, 0x29, 0x03, 0x33, 0x03, 0x04, 0x25, 0xb2, 0x6f

<snip>

2018-05-30 21:59:16.824 Info, Node041, Response RTT 37 Average Response RTT 36
2018-05-30 21:59:16.824 Info, Node041, Received a updated Color from Device: #FF0000
2018-05-30 21:59:16.824 Detail, Node041, Refreshed Value: old value=#008000, new value=#FF0000, type=string
2018-05-30 21:59:16.824 Detail, Node041, Changes to this value are not verified
2018-05-30 21:59:16.824 Detail, Node041, Refreshed Value: old value=13, new value=3, type=list
2018-05-30 21:59:16.824 Detail, Node041, Changes to this value are not verified
2018-05-30 21:59:16.824 Detail, Node041,   Expected reply and command class was received
2018-05-30 21:59:16.824 Detail, Node041,   Message transaction complete

I perused the light.py in the zwave component and it’s always (seemingly) sending a variable called ‘rgbw’ which must have information other than just the RGB light color. Maybe need to modify this file as well with a quirk for this device?

11

What is the value of the light entity’s supported_features attribute?

12

I think the zwave integration code is pretty broken. The ozw version of the code has been updated quite a bit to properly support RGB. I think your problem is related to this section of code:

It correctly sets the RGB values. It then checks if a white value is supported, which in your case is not true, but the last else is incorrectly appending the white values to the color string anyways.

OpenZWave doesn’t really care what values you set, it just passes them to the device. It’s looking like the device ignores the command if unexpected color values are set. I suspect if you delete the else block it will work properly, at least in your case.

13

Supported features is reported as 49, I think the following is the decoder ring:

SUPPORT_BRIGHTNESS = 1
SUPPORT_COLOR_TEMP = 2
SUPPORT_EFFECT = 4
SUPPORT_FLASH = 8
SUPPORT_COLOR = 16
SUPPORT_TRANSITION = 32
SUPPORT_WHITE_VALUE = 128

I played with that section including hardcoding rgbw to “#ff0000” and somewhere the additional 4 0s are still being appended before sent to the the device. I wonder if it has to do with “SUPPORT_WHITE_VALUE” being set – there is a comment in the light.py file that “openzwave appends white channels that are present”. I don’t see where these bits are set, it doesn’t look like in discovery.

14

It’s not set, you just said so yourself. 49 is BRIGHTNESS, COLOR and TRANSITION, which matches your xml cache file.

It looks like there is yet again another bug with this code. If you don’t specify a white value, self._white is set to 0 (line 381). So it’s actually line 390 where the extra values are set, because 0 is not None.

15

Also, don’t forget to restart HA if you change any of the component files.

16

Yeah, major brain slippage LOL. I have been restarting HA after making changes, I still think something else is modifying the result. I have the following as the last few lines in the file:

        rgbw = "$ff0000"
        self.values.color.data = rgbw

        super().turn_on(**kwargs)

I explicitly set the variable to what I want it to be and the additional zeroes still get sent. The entity also reports rgb_color of 255,255,255 so something is broken in the way the status is being read back as well.

17

I must have been pretty tired or distracted last night. I was making changes to light.py in the git repo, not in my custom_component folder. Commenting out the suspect if/else section (Homeseer HSM200 Zwave LED On/Off and Color Control) along with the discovery changes (Homeseer HSM200 Zwave LED On/Off and Color Control) allow the light to be controlled. I’m using the light.turn_on service call with this data:

entity_id: light.upstairs_motion_led
rgb_color: [255,0,0]
brightness: 255

Also working instead of rgb_color:

color_name: Red

The list of colors is in the zwave config xml (or in my original post in this thread).

For some reason the first command issued throws an error, the second works and this pattern continues so I still need to look into that. I also plan to come up with an acceptable pull request to fix this in general, and reference that with a feature request to the new ozw integration to have it fixed there as well.

Thanks @freshcoast for the help! I’m marking one of your posts as the solution and I’ll edit my original post to point to this one as a summary.

1 Like
18

@inkblotadmirer Did you have to do anything with the existing Home Assistant Zwave integration before or after you added the entire zwave files with the edits suggested into the custom component folder? Can I have a custom zwave component running simultaneously with the preloaded config options for zwave? I’m excited to give this solution a try as I just bought 3 of these sensors, but I’m nervous about messing up the rest of my zwave network of 25 devices.

19

I cloned the home assistant core repo, and created my own custom branch (as a separate user, in a non-HA location). Here is my git diff:

diff --git a/homeassistant/components/zwave/discovery_schemas.py b/homeassistant/components/zwave/discovery_schemas.py
index f8674a48a3..aa0874fd57 100644
--- a/homeassistant/components/zwave/discovery_schemas.py
+++ b/homeassistant/components/zwave/discovery_schemas.py
@@ -295,11 +295,13 @@ DISCOVERY_SCHEMAS = [
         const.DISC_GENERIC_DEVICE_CLASS: [
             const.GENERIC_TYPE_SWITCH_MULTILEVEL,
             const.GENERIC_TYPE_SWITCH_REMOTE,
+            const.GENERIC_TYPE_SENSOR_NOTIFICATION,
         ],
         const.DISC_SPECIFIC_DEVICE_CLASS: [
             const.SPECIFIC_TYPE_POWER_SWITCH_MULTILEVEL,
             const.SPECIFIC_TYPE_SCENE_SWITCH_MULTILEVEL,
             const.SPECIFIC_TYPE_NOT_USED,
+            const.SPECIFIC_TYPE_NOTIFICATION_SENSOR,
         ],
         const.DISC_VALUES: dict(
             DEFAULT_VALUES_SCHEMA,
diff --git a/homeassistant/components/zwave/light.py b/homeassistant/components/zwave/light.py
index 244b4a557e..d6e777d7a8 100644
--- a/homeassistant/components/zwave/light.py
+++ b/homeassistant/components/zwave/light.py
@@ -386,10 +394,11 @@ class ZwaveColorLight(ZwaveDimmer):
             rgbw = "#"
             for colorval in color_util.color_hs_to_RGB(*self._hs):
                 rgbw += format(colorval, "02x")
-            if self._white is not None:
-                rgbw += format(self._white, "02x") + "00"
-            else:
-                rgbw += "0000"
+            if self._supported_features & SUPPORT_WHITE_VALUE:
+                if self._white is not None:
+                    rgbw += format(self._white, "02x") + "00"
+                else:
+                    rgbw += "0000"

         if rgbw and self.values.color:
             self.values.color.data = rgbw

This entire zwave folder then gets copied to custom_components in your homeassistant/.homeassistant location. The changes are fairly small, it’s fine to just copy the zwave folder into the custom_components location and manually add/change the affected lines.

The changes made may affect other lights that fall into the “self._white is not None” categories or the added logic. This is the only light I have with a color LED, and I made no effort to truly understand the logic here. That, and the fact that this zwave implementation is on its way to being deprecated, is the reason for not submitting a pull request to get it fixed officially. Good luck!

EDIT: I inadvertantly clipped the top portion of the diff indicating the first file with changes. Fixed.

20

I should also add (since you asked) this shouldn’t affect any other zwave components (other than mentioned in my prior post, falling into the “self._white is not None” category.)

I took a look at my automations and it reminded me that I still did have some trouble getting these working correctly. I don’t recall the exact issue but my automations are calling the turn_on and turn_off routines twice. If I remember the light would only take one change at a time (like, not changing color and state with one command) but I don’t recall the specifics. In any case, here’s an example of the automation I’m using (I haven’t taken advantage of the variables and native types yet):

            sequence:
              repeat:
                count: 2
                sequence:
                  - service: light.turn_on
                    data_template:
                      entity_id: light.upstairs_motion_led
                      rgb_color: [255,0,255]
                      brightness: 255
                  - delay:
                      milliseconds: 250

Even though you can set arbitrary RGB values only one of the 16 supported colors will show. You can modify the automation to set these colors instead of the RGB value.

					<Item label="Off" value="0" />
					<Item label="Cool White" value="1" />
					<Item label="Warm White" value="2" />
					<Item label="Red" value="3" />
					<Item label="Lime" value="4" />
					<Item label="Blue" value="5" />
					<Item label="Yellow" value="6" />
					<Item label="Cyan" value="7" />
					<Item label="Magenta" value="8" />
					<Item label="Silver" value="9" />
					<Item label="Gray" value="10" />
					<Item label="Maroon" value="11" />
					<Item label="Olive" value="12" />
					<Item label="Green" value="13" />
					<Item label="Purple" value="14" />
					<Item label="Teal" value="15" />
					<Item label="Navy" value="16" />
					<Item label="Custom" value="17" />
21

Thank you both for sharing the workaround to get these sensors working.

  1. I cloned the ha core and made the edits as you both suggested last night,
  2. Copied the zwave folder into the custom_components.(I renamed my component hszwave),
    3.Added hszwave: into my configuration.yaml file
  3. Checked config and restarted and there was a light entity! (Okay, actually it showed up after my second start because I had to remove the “+” on the light file after my first restart which thankfully showed up in the log file).

You are right something affecting the service callI noticed right way I had to toggle the light entity switch twice before it turned on last night. And this morning, I had to turn it on and then select a color before it illuminated. I was able to do a quick motion detection automation that turns the LED Red with the light.turn_on service with one action only; but the LED previous state was Red, so that might have allowed it to work with one service call. I’ll make sure to add a repeat service call for good measure.

22

I also struggled with this.

But good news this seems to be fixed z-wave JS. I can easily set the led light for this motion sensor with my automations using the call services.light option.

Side note I did remove the sensor from my z-wave network and re-added it after converting to z-waze js. Not sure if that is required or not.

But so glad to now be able to easily use these sensor to there full ability.

23

Thanks for sharing your success with these on z-wave JS. I’m glad to hear it works by default now. I’ve been holding off on migrating to z-wave JS for several reason, but the fear of losing this feature was a top one after the help I received to get it working. Time to get my zwave network listed I guess.

24

Hey jwin32,
I just setup z-wave JS and can’t seem to get the HSM200 sensor setup correctly? At one point I was able to set color using a door sensor (mailbox notifier project) but I am having issues with motion reporting, it always shows a Detected status. I tried re-adding the device same thing. Another thing I noticed was after power cycling the sensor it would respond with the usual red indicator for motion but then that stops working after I set a color? I’d appreciate any advice, I’ve tinkered with HA for a couple months but z-wave is very new to me.

25

Hi @MrGiovanni,

I actually haven’t made the switch to z-wave JS yet, I was just commenting on how relieved I was to hear from @cass2115 it was working. I guess I assumed the post meant it worked by default with the new integration. Sorry to hear you aren’t having immediate success.

I did not see Command Class Color listed when I looked at the z-wave JS Command Class conversion status (which was the custom integration edits frescoat had provided originally to get the light to work marked as the solution), so I was initially skeptical if it would work in z-wave JS by default. There is a Color Switch row now, but I’m not smart enough to know if these are the same. You could always try removing and including the device again suggested, but for the specifics of how to get it working you might check with cass2115. I’m curious as well, since I relied on everyone else’s smarts to make it easy for me to copy and paste to get it working.

1 Like
26

I have a few HSM200 devices and one EZM. The appear physically the same, except for the EZMultipli logo on the EZM. In Z-Wave JS the HSM200 devices now have a light entity that I can use to control the indicator, however the EZM does not. Interestingly, the HSM200s show brand of EZMultiPli and firmware 2.2, the EZM shows firmware 1.10. When I get time I’ll look at the Z-Wave JS code and look into if the EZM needs a firmware update or what but it might be a while before I can do that so hopefully someone else can get it working sooner.