Device Handler for NodeMCU using MQTT?

There isn’t anything more easily controllable.

I think you need to read up on the documentation and get a better idea of the relationship between a device Handler and an actual device.

1 Like

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

He’s not really being an ass, and I get his point… Text doesn’t convey tone very well, so let’s all just back up a little bit.

The reality is, a DTH DOES exist that handles 90% of what you and I are looking for, but it is written to use a different hardware solution. You can install the DTH, add a device in SmartThings, real or virtual, assign it to use that DTH, and it will be fully functional, assuming the device exists in real-life.

Edit the existing DTH to point to a different type of device using a different protocol (if required), and that same DTH can now control a completely different piece of hardware with similar functions.

It sounds like @TRDeadbeat is on the case to get that going with @vseven’s DTH.

2 Likes

Exactly. Again @Ryan780 I don’t think you are understanding the relationship between the device Handler and the device you will be using to do the actual control. I’m not being a jerk, you just don’t seem to want to learn the difference and therefore you’re not going to get very far with this.

If you can’t take the 15 or 20 minutes to read the existing documentation to understand the differences then why should I spend my time trying to explain it to you?

What don’t you think I’m understanding? I understand fine. Point me to where there is an existing DTH and I will eat my hat…because you can’t. Correct?

Bottom line, you don’t want to help so why bother.

If you understood we wouldn’t be having this conversation…

You’re missing the point. The DTH is what defines what the device can do. While it might be written to communicate with ST_Anything, it can be edited so that it can communicate with a RestAPI/MQTT/WebSockets, etc.

What you are saying is clear, but what you seem to be missing is that it can be edited to use something else.

@vseven’s DTH could be edited to work with the H801 if someone were so inclined, or the Tradfri, or, or, or. It just takes some development skills which I do not have.

What Allan is saying is that most of the work for the color aspects of the DTH are done. No need to start from scratch if you just have to drop down and edit the “what am I talking to” sections and set them up for the appropriate parameters. More than just changing a variable or value, but less than writing an entire DTH from scratch.

2 Likes

EDITED!!! EXACTLY MY POINT. Thank you for making my point for me. I said up front that I don’t know enough to do that. So, what the hell is your point?

We’ll just call the conversation good then, and shake hands on it. :stuck_out_tongue:

Lol. Same to you buddy. :slight_smile: I can deal with somebody who doesn’t know something but not with someone so ignorant they’re not willing to learn even the tiniest bit on their own. Good luck with your device Handler.

I didn’t say I wasn’t willing to learn. In fact, I’ve done a lot of learning on my own. But you’re not telling me anything other than “learn”. Okay, where? How? You make it sound like I’m sitting here stomping my feet like a child. But you’re not giving me anywhere to go to get info or any direction or hints. You make it sound like everyone should just know this stuff.

And telling someone who’s asked if there is a DTH for something that they should go and write it themselves is the very model of completely unhelpful. If i knew how to write it myself, i wouldn’t come here, would I?

http://lmgtfy.com/?q=SmartThings+documentation+device+Handler

Try the first link. After that look through the public GitHub repository for SmartThings device handlers:

In particular you can look at anything that has RGB or RGBW in the device handler name. The majority are going to be zigbee or Z-Wave so you will see commands sending to those types of devices. My DTH is actually much simpler than all of those because it is part of ST_Anything and I’m just sending the one single command with a hex value to tell the LEDs what they should be doing as pointed out above. Again the dth could be used with almost any device but the problem is you have to figure out what device you are using for your neopixels and how to interact with your device.

1 Like

Wow, i was gone for awhile and all hell broke loose here :slight_smile:

@vseven your DTH is working out very well and i’m making good progress to getting my project up and running. Thank you very much for the work that went into it!

It’s looking like the best solution for managing queue messages is to just let the MQTT-Bridge smartapp handle it. I had originally aspired to push custom messages to the queue from your DTH but that’s turning into a huge pain in the ass… So instead i think i’ll adapt the ESP’s code to match the existing MQTT-Bridge. So basically, a few small tweaks to your DTH, and comment out anywhere it sends a command to ST_Anything and i think i’ll be golden.

I did find two potential bugs in the DTH code that i wanted to make you aware of - i don’t know if this is the right place to post this or not… yell at me if it shouldn’t be here:

  1. in hueToRgb() line 380:
    if ((3 * vh) < 2) { return (v1 + (v2 - $v1) * ((2 / 3 - vh) * 6)) }
    This throws an error when attempting to minus between a character and number due to the ‘$’ in (v2 - $v1). Removing that $ resolves the problem.

  2. in setColor when detecting hue and saturation, on line 175 you’re using:
    } else if (color.hue && color.saturation) {
    However, when setting the color to red, the hue is “0” which causes this condition to eval as false. I changed it on my side to || instead of &&, but you may have a better method.

2 Likes

A lot of that was copy and paste from existing DTH’s, i.e. i didnt write the hueToRgb function, which means the “official” SmartThings handlers also have those bugs. Wierd that I haven’t had any issues with it on my RGB LED strip, at least that I’ve noticed. Maybe its a recent change in how its evaluated. Either way I’ll make those changes to both the RGB and the RGBW handlers in ST_Anything. Thanks for posting the fixes.

EDIT: Yeah…the official one I used as my base has the same issue with the hueToRgb. Example: https://github.com/SmartThingsCommunity/SmartThingsPublic/blob/master/devicetypes/smartthings/fibaro-rgbw-controller.src/fibaro-rgbw-controller.groovy I’ll put in change request on that and point to your post as reason for the change.

1 Like

Sounds good - i found another issue related to HSL to white - the lightness modifier is hard coded to 0.5, which in turn converts to 128,128,128 when hue and saturation are both 0 (alexa’s “white”), which means white is at most 50% brightness after conversion. I’ll follow up with a change request on this one as well.

Also, my original change for #2 in my last post doesn’t work for white (another bug in the code i think), because on white both of those are 0 and cause the eval to fail even when using OR instead of AND. My last update changed line 175 to:
(color.hue || color.saturation || ( color.hue == 0 && color.saturation == 0 ))

I’m sure there’s a better solution, i’ll keep thinking on it. One quick question while i have you @vseven then i’ll let you go about your life again :slight_smile: - do you know of a way to expose custom colors to Alexa? I want to use these “colors” as a way to trigger the effects by voice (i.e. set blahblah to rainbow).

In other news, my light strip is up and running and working with Alexa minus the effects - those can only be triggered in the ST app so far. :slight_smile: I have some cleanup tasks but i’ll post some info soon for @Synthesis and anyone else that wants to get this up and going. It does require MQTT, and updated Arduino code along with the DTH… but it works.

I don’t think there is any way to add custom colors to Alexa. Somewhere on these foums I have a post about voice enabling a DTH and from what I can tell both Alexa and Google have a list of colors they support but I don’t remember seeing the actual list. I have to assume it’s out there somewhere. But I don’t think you can modify anything about it.

As for the lightness being hard-coded to a 0.5 I saw that too but it didn’t really bother me as I was only looking for the colors and I use the level slider in my dth to determine the actual “brightness” setting which seemed to work. So if my brightness is at 100% and you tell it to set the lights to Blue it would be 0000FF for full blue.

As for the comparison I thought in my original code the and was just looking for the existence of those values, not necessarily them having a value. What I mean by that is if we use Alexa or Google home you will not have a hex value but you will have the color and Hue values. Again I swear the code worked as it was previously so I’m wondering if something in the evaluation has changed.

Did some hunting. Here is how SmartThings is doing the check in one of the Hue bulbs. First they have this check routine at the very end of the DTH:

def verifyPercent(percent) {
    if (percent == null)
        return false
    else if (percent >= 0 && percent <= 100) {
        return true
    } else {
        log.warn "$percent is not 0-100"
        return false
    }
}

Then in the setColor routine they have this (there is more but this is part of it):

if (verifyPercent(value.hue)) {
    validValues.hue = value.hue
}
if (verifyPercent(value.saturation)) {
    validValues.saturation = value.saturation
}

They then use the “valid” values. With that said to bring it more in line to ST:

} else if (verifyPercent(color.hue) && verifyPercent(color.saturation)) {

Might be overkill but it should work better?

Nice find. My modified implementation is basically the same, but all inline in the if statement… This is a more concise implementation.

@TRDeadbeat Where did this end up?
I’m now up to 14 discrete ESP8266 NeoPixel devices around the house, and I’m currently controlling them all directly from their web page… I’d really like some ST enabled functionality.