[BETA] Edge Drivers for Homeseer Devices

@futuretek

Thank you for the feedback loop.

  1. I am aware of the App sync issue, and that is consistent across the drivers at the moment.
  1. I took a look at the code which was duplicated from the EzMultiPli and I can see that the issue is that the code does not expose the LED as a sub-component and/or child. I should be able to push some code shortly to “expose” that functionality.

  2. I will need to look into the timeout a bit further, as the currently code (which I had just extended), does not include this functionality and it is not embedded into the native HomeSeer controls.

1 Like

I pushed another release to production. There was some significant refactoring performed (which could have introduced some bugs), but the intent was to segment the common code across the Switch/Fan and potentially the Sensors (think button/profiles/led control/colors etc.) In doing so, I was able to attempt some level of feature parity between what has been release for the switches and the FC200.

In any case, I will look into color control from the app. This is separate functionality then the color control which is triggered from a routine/smart lighting, but in the new structure, resolving on one device should ripple across the other devices as a single code base.

1 Like

Thank you for your help on this. The HSM 200 seems like one of the more complicated devices so your ongoing support is appreciated.

To confirm, my sensor should automatically receive the recent driver changes that you pushed to production, right?
If so, I will do another round of testing today and let you know the results.

@jshessen I retested and got the same results I noted above. No new issues were observed.

Please keep me looped in on your progress.

Thank you

@futuretek well that is good news (and expected behavior) as no additional functionality for the HSM200 was release last night. So status quo is better than broken :wink:

PS – I have already begun to look into both reporting the active/inactive motion state, but also adding an additional setting parameter for handling a motion sensor delay which would prevent the active notification state from “announcing” itself for a period of time.

1 Like

Folks, I’m a keen onlooker to this thread and am also thankful for the efforts in developing these drivers. I have a number of WD200+ switches, and have moved some of them over to these beta drivers. The driver available when I first moved them was dated 2/9/23 I believe. Today I see through the SmartThings app that my switches seem to have the 2/14/23 release. However they do not appear to be interacting with SmartThings at all - simple example I cannot change the color of the LED or even turn on/off from the app. I also experience the network error issue.

Must I exclude/reinclude each switch to take advantage of new drivers that are delivered?

Thanks again.

@rodcmarr you should not need to exclude/include. As the code is pushed to the channel it typically rolls out across within 12 hours (so you have the latest code set).

You 100% found an issue with the code rebase. I have just released a fix which should get you back into some sort of working order.

smartthings edge:drivers:install -C c86f153c-e354-4ac3-b28f-811d2eff958f 67768d73-9b40-4ed8-b873-d251fb54a7bd
1 Like

@jshessen I appreciate everything you are doing to optimize the driver.
Of the 3 issues I noted above, I would say that making the HSM 200 LED/RGB light function like it did with the groovy DTH, is my highest priority. Without the capability to turn on the light with different colors, the sensor is pretty much useless for my use cases.

The motion sensor cool down setting is a close second in priority, but I can compensate by using other motion sensors to handle my automations.

I will be traveling for business the next couple of days but I am happy to carve out time to test if needed. Let me know if there is anything else I can do to help.

1 Like

@futuretek just for my knowledge, have you tried using a routine or smart lighting automation to “trigger” the color change (vs. the app/ui)?

I ask, as the code appears to be present to set the color based upon the colorControl capability.

@jshessen Yes I created a routine that sets the color and it unfortunately had no effect when the automation fired.
Here is a screenshot of the test routine that executed previously. I got the text message but the sensor color I set did not happen

1 Like

I pushed the next code release this evening (Switches/Fan Controller/HSM200).

My focus was to eliminate the sync/latency issue in the application, and to re-work the various profile settings to be marginally easier to consume.

I have validated:

  • multi-tap functionality
  • local/remote on/off/dim
  • LED on/off with Routines
  • LED color push via Routines

Known Issue:

  • Smart Lighting - I am not sure what I have going on with the Smart Lighting app, unlike routines you are only able to select a single color to push. When doing so only one LED seems to get the colorControl command. Additionally, the app seems to dislike selecting of the components, and unless all LEDs are selected in unison it tends to fall back to LED-1 or even the switch itself. I suspect this is the root of what we are seeing with @futuretek on the sensor side of things as well.

In any case, please feel free to provide any relevant feedback. I will take some time over the next week to explore the introduction of the LED Blink functionality (I believe this is the only remaining vendor native capability not currently exposed) and look into what is going on with the Smart Lighting controls.

@JDRoberts – Based upon the HomeSeer ‘official’ it looks like the SmartLighting limitation is present on their end as well. So with a bit of focus on the blink components re-enabled I would say that we should be largely at parity.

1 Like

@jshessen If I am interpreting your message above correctly, it sounds like your recent release did not address any of the HSM200 issues I noted above.

Even so, I went ahead and did a quick test with your new driver. Unfortunately, I found a new issue!

The HSM200 lux sensor was working as expected with your prior release. However, with the latest driver update, lux is no longer reporting correctly. It’s daytime where I am now. There is lots of light, but lux is reporting 0.

At this point, my device is no longer usable. Temperature is about the only capability that seems to report correctly.

Though the results so far don’t look promising, I still very much appreciate the time you’ve invested to keep this community going.

Unfortunately the groovy DTH door is closed for me since there is no way to revert or downgrade back to it.
So is there anything creative you can pull out of your bag of tricks to resurrect my HSM200?

Also, let me know if there is anything else I can do to help move things forward

@futuretek just to affirm, I had made some additional code tweaks for the HSM200. Specifically, I was adding the CommandClass Notifications which would be used to create a delay between motion events. I just commented that out for the moment, and pushed a code set (which also includes some profile/settings clean-up). Together, I hope we can get you sorted out as I am actually quite hopeful that the work down prior should be able to enable the color controls you were originally looking for (via Routines not Smart Lighting).

EDITAfter the initial post, and because of some of the code modulation, I was able to push the FC200 code set as well. I am unable to test this locally, as I do not own any of these devices.
EDIT/EDIT@futuretek I didn’t forget about you. Without a device to test locally, I am flying a bit blind, but I did update the sensor code to use the color controls which was pushed to the Switch/Fan drivers.

Alright, I was hoping to get it out last night, but I wanted to finish cleaning things up. As of this latest release, I believe that we are pretty close to feature complete.

The latest version of the code handles:

  • all multi-tap functions
  • can automatically adjust the device profile based current firmware and/or Normal vs. Status operating mode (you have to leave the settings page and return to see the update profile)

    **
  • included a reference to the current “in-use” profile on the settings page
  • has full LED representation as a device component (LED-1 through LED-7)
  • can successfully handle all of the vendor parameters
  • exposes a series of settings which allow for the LED Blink functionality to be controlled from the device settings, and honors that Blink Frequency of 0 stops all LED blinking (overide)
  • Although the device can only handle 7 colors (Red/Green/Blue/Yellow/Magenta/Cyan/White), the driver can handle any inbound color and will translate the HSL definition to the nearest supported color (Black = Off)
  • updated the channel meta information to be as descriptive as possible
  • modified the driver definition to list the supported devices

I have significantly optimized the code and introduced multiple error handlers to things as quiet as possible.

From testing perspective:

  • I have used Control Scenes to turn devices on/off/dim level for both HomeSeer and non-HomeSeer devices
  • I have used open/close sensor to trigger LED on/off and color changes (via Routines)
  • I have confirmed that the app/UI has near instant sync (within the bounds of SmartThings)
  • I have mapped Virtual devices to the components to control via voice assistant (sync of virtual device colors is a known Smart Lighting limitation)

The general recommendation for ColorControl triggers is to handle through either Routines and/or Rules API. The current Smart Lighting application seems to have challenges in addressing device components.

Please let me know if you find any issues/errors or if there is a compelling feature you would like me to look into. My focus will be to quickly port this level of capability over to the FC200 as a next step.

smartthings edge:drivers:install -C c408fa0b-438f-4d00-bf36-efe7343c66b7 5f2d5dca-fcd9-4895-805a-6e976dd349d1

Hi @jshessen i saw the updated driver so I ran a couple of quick tests of my HSM200 sensor using routines.

Unfortunately, I still have the same issues with my sensor. Plus it took a step back because now it has no motion sensing ability. Motion sensing seems to have stopped working in the last two releases.

Here is a quick summary of the issues I am observing:

  1. the sensor won’t power on via the card or through routines. Powering on via the card results in a network / server error as indicated in my prior screenshot. This feature hasn’t worked in any version of the driver

  2. motion sensing no longer senses movement. Bug likely introduced in the 2/16 release

  3. lux sensor value is 0 even in daylight. bug likely introduced in the 2/16 release

  4. Setting the LED color via the card or routine does not have any effect. This feature hasn’t worked in any version of the driver

  5. a temperature value does show on the card so that something I guess

NOTE: Unplugging the sensor and plugging it back in does cause the LED to show a blinking white light for a few seconds. After that initial step, the light goes off and nothing works via automation after that
.
Not sure where we go from here. If you have other ideas please let me know

1 Like

My switch stopped turning on or off the light from the ST app, works at switch as well as double tap at switch.
Don’t know if related to the new firmware update or not.

@RottenMutt – I was able to confirm the issue on the WX300 (suspect the WD200 as well), but the problem was not showing on the other 100/200 series. In any case, I was able to handle this scenario and validated local/remote/button control for both 100 & 300 series switches.

i don’t do anything to load the newest driver do i?

Technically, no… But it can take up to 12 hours. I have found if you issue the smartthings command above it will force a lifecycle event which seems to force a refresh.