@DrDraake – no need to be sorry, most of us are here to help where we can.
Unfortunately, the situation with the HSM200 is a bit in flux. From what I can see the EZMultiPli is essentially the same device, and has been developed and already included directly in the SmartThingsCommunity/SmartThingsEdgeDrivers channel.
I have issued a “pull” request to add the HSM200 to the device definition, but this pull request has yet to be reviewed..
As a stop gap, I will work on adding temporarily pulling the code over into my device channel today/tomorrow to offer this functionality until it is properly incorporated into the main channel.
@jshessen I appreciate everything you are doing to enable these drivers!
Your work is much appreciated. Thanks so much
I don’t have a an HSM200 to test with, but I have incorported the changes that were included in the pull request to the main channel into the channel documented in this thread. To keep things generic, the driver is referenced as “HomeSeer Z-Wave Sensors”. Feel free to give it a go and provide any testing feedback (may require some logs if things don’t work).
smartthings edge:drivers:install -C c408fa0b-438f-4d00-bf36-efe7343c66b7 f8c65d66-292d-4f61-947e-b3025067b076
Doesn’t enroll properly, no zwave device id or hub ID, see below.
Could be problem with hub memory full. Still way under max devices.
Edge devices do not populate those fields in the IDE. The most you get is the name, label, and a device type of “placeholder”.
Re-enforcing @csstup here is a screenshot of one of my devices as well.
The key item to look at is to view the Driver details in the mobile app:
- Select a Device
- Click on the “menu” (three dots upper right of the Android app)
- If you see “Driver” then you are using and Edge device. The details will show you which driver you are using.
The IDE is part of the old architecture and will be going away once the transition to the new architecture is complete.
Once a device has been assigned to an edge driver, any edge driver, the information in the IDE may be incomplete or inaccurate or old. Just ignore it.
Instead, there are now three places to look for the information you used to get from the IDE.
as @csstup suggested, just start with the device details in the smartthings app.
if you need still more information, try
Which is a new official feature.
- and if you need even more details, you can use the CLI or a community-created webpage called API browser plus
SmartThings API Browser+ ... Now Available to All
But lots of things are going to look weird in the IDE now. They aren’t bothering to update it since it’s going to be eliminated anyway.
You can find additional information in the following community FAQ:
Life after the IDE: Questions and Answers
It works. But need way to organize routines…. Folders would be good, or ability to add all scene control routines to one routine.
@jshessen, Thank you for developing the driver.
@jshessen I did a bit of testing and here are my results.
The good news
I was able remove my HSM200 and successfully re-add it to Smartthings
the correct driver was selected after adding it
I am able to see temperature, lux, motion and color settings as expected
lux and temperature values report correctly
The bad news
turning the sensor on or off from the app results in this message “network or server error occurred. Try again later”.
Also does not turn on from routine.
See screenshot below for more details
setting any color from the app or routine does not show the color on the sensor. This is the main feature that I use this device for so I hope this can be corrected
Motion sensor timeout value is no longer available under the sensor Settings menu. After motion is detected, it takes 10 minutes to clear! This makes its use as a motion sensor very limited. It would be great if you can re-add the ability (under the sensor Settings) to set a value (in seconds) to clear motion detection. As an example, my other motions sensors clear detection after 15 seconds of no activity which is perfect for me
Other than those issues, everything else seems to work fine.
Thanks you so much and I appreciate your help to correct the issues I noted above
Thank you for the feedback loop.
- I am aware of the App sync issue, and that is consistent across the drivers at the moment.
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.
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.
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.
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.
@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
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.
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?
@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.