@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
@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.
@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
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
- 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.
@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).
EDIT – After 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:
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
motion sensing no longer senses movement. Bug likely introduced in the 2/16 release
lux sensor value is 0 even in daylight. bug likely introduced in the 2/16 release
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
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
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.
that fixed it…
i had to down load smartthings.msi tool from Releases · SmartThingsCommunity/smartthings-cli · GitHub
and then run from command prompt what you quoted…
I just migrated one of my HS-WD200 to your driver to specifically test the individual LED colour control.
I found a couple problems that I would like to understand. Things have changed from the previous DTH and there are some things that don’t seem possible anymore.
First, I used to be able to switch from the “Normal Mode (Load)” to “Status Mode” from a scene, routine or SL. Now, the parameter is not exposed externally. That makes it impossible, for example, to display a special status temporarily, like and open door, and come back to the “Load display” once the door is closed. The way the Switch Operating Mode is built in the driver as it is now, is like if the dimmer should be used in a way or another definitely. Whether I think this mode should be dynamic, like display the load under normal circumstances, but switch to status to show something temporarily and come back to load after that is resolved.
Another problem I found is if you want to create a routine to activate or change the color of an LED, the main relay “has” to be activated or disactivated. I have so use cases where I would like to only alter the LEDs and not the light relay itself. That is not possible right now. I also tried in SL but as you mentionned ealier, I noticed many things are not working properly.
FYI, I am using version 2023-02-20 of the driver.
Homeseer has released a manufacturer’s edge driver for that specific model which is out of beta and is supposed to have full functionality. They’ve only done a couple of models so far, so the community-created driver in this thread does have many more models, but is still in beta, and may not have quite as much functionality for some models. So you might want to give the other one a try and see how it works for you.
Also, there is a discussion in that thread of a bug in the app which is causing the turn on issue you reported.
[ST EDGE] [RELEASE] Homeseer Light Switches, manufacturer-provided edge drivers
I’ll give it a try.
Thanks for the quick response.
I am somewhat optimistic that the release I have provide most recently is in parity with the “Official” capability, and thus the request to provide any feedback and/or performance issues which may exist.
From what I can see, I believe that this release has additional functionality both in terms of included device, but also in terms of how to interact with the LEDs.
With that being said, I am interested in potentially exploring some of the ideas that @KrankyFranky has mentioned.
One of the on-going debates is the use of a Device+Component vs. Parent Device + Child Devices.
Up until this point, I have been focused of extending this driver set into using the components (despite the limitations related to voice assistants for not using child devices).
One of the nuances of this approach, is that the driver “profile” definition is essentially static. A shift from Normal to Status requires a change in profiles to build out the components. One of the concepts I have considered exploring is to extend to additional “Operating Modes”. This could include the native modes of Normal/Status to something like:
- Status (+ 7 LEDs)
- Normal + Color Control?
- Status + an All LED component?
I have a rule in place today, which I have used for testing, and it Will turn 2 LEDs Red if a door is unlocked and Green if the door is locked. This is not dependent upon the load being “on” to control the individual LEDs, so I would be interested in more feedback here.
So just to follow up on this, I have been able to test the official Homeseer driver. It’s behaving exactly like the previous one I had before from krlaframboise. I’m able to togle the LED mode from load to status from a routine or a scene. I haven’t tested with Smart Light.
So I can only say that this new driver works perfectly for my needs. I only migrated 1 dimmer so far, with 11 more to go, but I tested all the LED controls that I currently use and it’s working.
With regards to the main relay, I found another thread mentionning this limitation but apparently it is fixed now. If you don’t want to activate the main relay, you simply have to click on it to remove it from the action. The togle shows a radio button to activate or deactivate but apparently they are independent, not acting like a real toggle would.
@jshessen, your question about the profile. I think there should not be 2 different profiles. Just one that exposes all the LED all the time. You should have a look at how the official HS driver is implemented and you will see that every single LED is exposed all the time in the device screen. If you set an LED to go a certain color, I guess it will still send the command to the dimmer but I will only start showing on the dimmer itself once you togle the status mode on.
I hope my explanation is clear as it’s kind of difficult to explain without a screenshot which I can’t do at the moment.