[Release] zigbee2mqtt EcoSmart Remote ZBT-CCTSwitch-D0001

⚙️ Custom Apps and Drivers
8

Thanks for that. I think the PR got massaged slightly by the repository maintainer.

Also, the official implementation is going to change soon - the changes are currently in the zigbee-herdsman-converters project, but not yet set up in the dev branch of zigbee2mqtt. See this PR for more details:

Summary: What I called "action" is being move to "click", and the various "click" values will be "power", "brightness", "colortemp", and "memory" instead of button numbers. The new converter also passes along the values the remote sends, if you care about the state the remote maintains (my driver code ignores that data). It also supports holding button 2/3 (but don't hold button4, or you'll break button4 until you reset the device).

I've updated my device code for Hubitat in my github repository. The parse method is changed to account for all three possible driver versions and for holding buttons 2/3 in addition to clicking (if your zigbee2mqtt is updated with that driver).

9

Thanks for the heads up. I like Hubitat but the open source implementations of a Zigbee implementation seem to be progressing and are getting support for more devices. I think I will start playing with the Zigbee2MQTT and Home Assistant. I like the idea of using MQTT as a backbone to home automation and being able to use different ways to create automation.

1 Like
10

I am sort of on the fence on this but beginning to lean that way Hubitat needs to think about how to leverage opensource zigbee work. That way they wont have to worry about being too small to do this or that.

11

@mbafford thanks for your help - so I have have the hw, got the firmware installed and remote associated. I can see button presses in logs. Haven't done MQTT on Hubitat before -
I assume I will have to make a new device for each remote and use your driver.

What I am not clear on is how do I get other devices to Hubitat, I figure I will need to put a couple of repeaters on this zigbee mesh so the signals can travel. I was thinking of putting a couple of Iris outlets, They report power consumption data as well. Currently they are on the Hubitat mesh, Once I put them on zigbee2mqtt mesh how do I control them from Hubitat and get their status?

Cheers

12

Correct, the way my driver is written, each remote has to be a separate device in Hubitat. I don't think you can get around that as such, since the MQTT connector is only available to a device, not an app. It could be possible to write an app to manage a single MQTT proxy device and then control multiple child devices - although I'm not sure that simplifies things any - and probably only has the benefit of using a single MQTT connection.

I'm not entirely sure about pairing other devices with zigbee2mqtt, but once you do so I think you'll need a custom driver to handle making the MQTT device into a Hubitat device - the same as I did for the remotes. Someone invested in that could make a generic driver for each general device type.

I did play with pairing my zigbee2mqtt install with multiple bulbs to try to strengthen the remotes' range. That was not as smooth as I'd hoped. The EcoSmart bulbs in this thread paired fine, but my Commercial Electric bulbs only paired once I added the EcoSmart bulbs into the system - as if the zigbee2mqtt couldn't talk directly to them at all. I ran out of time to figure that out.

Note, my code as posted does not handle disconnect from MQTT at all. I've proven that in my testing, but I haven't made any effort to fix that yet (and won't be able to until mid-January, if at all).

I'm not convinced I'm sticking with the Hubitat ecosystem. I'm pretty frustrated with how bad the developer support is and how much more closed the platform is than alternatives. Even SmarterThings releases their device handlers and apps code in an easy to browse GitHub. (Please correct me if I'm wrong about Hubitat not sharing theirs).

13

It't not clear to me whether the internal drivers they write are groovy or java and complied in, have a suspicion they reason the are closed source is that they are not groovy.
I have done the gambit from openhab, hass, pimatic, wink, smartthings, and now hubitat. I am getting a bit annoyed by we are not big enough answer, and their zigbee implmenation is so/so - I never had any problems with zigbee devices either on ST or Wink, did have problems with their cloud going out to lunch. I find HE zigbee to be pretty bad, and am keeping most bulbs on the hue hub. I had a fine mesh for years and with HE I had to put in extra repeaters, even then I constantly miss motion sensors and the delays seem be be longer for turning on lights on motion detectors in all zigbee then when I was doing hacked up X-10 drivers with ST on the cloud.

Also not a big fan on RM - I have a handful for rules and its taken more than an hour to just "code" a simple dimming rule for a button press like so -

Why cant I just use a scripting language like almost any other HA system.
The Pros for me are

  1. Local Control
  2. Packaged commercial stuff so for 90% of the things just work for basics
  3. Zwave and Zigbee Radios
  4. Maker API and websocket interface which gives abiltity to interface with other systems like nodered, Homebridge, influxdb etc.

Cons are:

  1. Increasingly getting opinionated about what they will support and what they won't
  2. Theri programming model doesn't really allow them to leverage the community as much as as ST did, they adopted a lot from ST but It seems like they have really cut off community from doing any real dev for Zigbee, unlike ST. Now I haven't delved into custom zigbee drivers much so just saying it based on cursory perusal.
  3. The undocumented websocket interface hope its stick around and becomes official
  4. And the is the biggest gripe rule definition is horrendous, non-portable and tedious, if you lose or have to do a device lost a ton of hours of work will be lost.

For me I will stick with HE for now because I have a mix of Zwave and Zigbee and it does give me a unified interface for them under local control. However I need to "extend' it and I am really looking for an alternative to HE may be something node-red would help, not too sure about latencies that will come in the system. But I just dont have time to define the rules that I need to do my automations, and i am not talking about complex things a simple 4-5 condition if-then-else switch take forever to define.
However with all other things going on in their universe i dont know how much of this is on their list.

14

I am seeing a latency of a little over 2s between a button press and an action, trying to find out where the latency is. I see that RM takes a while to process but also noticed a 500 ms delay in this code -

sendEvent(name: "pushed", value: button, descriptionText: desc, isStateChange: true) pauseExecution(500) sendEvent(name: "pushed", value: null, descriptionText: desc, isStateChange: true)

@mbafford why the 500 ms delay? also shouldn't the order be reversed send the general pushed event first then the button?

15

I'm not near a computer right now, so this is just from memory.

My first press when the remote is sleeping has a delay while the remote wakes up. Once that's done, I haven't noticed any delays, but I'm not using RM, just the simple lighting rules.

The delay is after setting the momentary button "pushed" variable to the button number being pushed. The code then waits 500ms and then clears the pushed button. I don't think this is necessary - and may confuse some code, since now there is a "no button" button pushed as well.

I'd first check the logs for zigbee2mqtt and my device hander. Both should log nearly instantly as you press the button. If they are, then the delay is probably somewhere else.

Also, I agree with pretty much everything you wrote about Hubitat. Great idea that I think is understaffed, not quite fleshed out, and possibly going in the wrong direction for me.

16

That is good to know - I think RM sucks eggs. zigbee->MQTT->your app-> event is pretty much instantaneous when it hits RM it justs goes to lunch. I have sent an email to support and also posted this with detailed timings

Yeah you hit the nail on the head - for me its the same thing, their direction - what they are choosing to do vs not do. I see that they spend a lot of time on new devices, ST eco system evolved and became big because community was writing DHs seems HE writes a lot of DHs, they are not leveraging the community where they should.

For me the ideal system would be classic ST setup running locally.

I am really torn - I think I need to downgrade HE in my setup and use it only as i/o device but not sure what I want to use as the main system. I don't want to go through trying out the whole lot again, last time I tried Hass it took forever to even get setup, its overly complicated but seems to be gaining a lot of traction, I don't think I had successful setup even after days of trying. I used to like openhab, may be go back and have a look at that again, or pimatic

17

A little update -
I was getting really bad performance like close 3 secs between pressing the remote button and seeing the lights react so I moved almost everything off of HE.
Moved the bulbs to the hue bridge, and added a listener on node-red, made some simple rules in Node red to listen to zigbee2mqtt events and send command to either Hue brigde or HE using the Maker API. Everything is working wonderfully now.
I think your device driver needs some tweaking but honestly I don't know if it's that or the event system in HE. In any case handling the event in node red also bypasses the reconnect problem.

18

Thanks for the update. I will probably give Node-RED a try as well. I guess I enjoy the tinkering part - otherwise I wouldn't bother at all, but I do look forward to finding that perfect system. I may or may not refine the code I've written for Hubitat - but for now my winter vacation is over, so time for that will be a bit more limited.

19

Can this be used to integrate the Ikea remotes as well?

Just putting that out there since they are another popular remote and supported by zigbee2MQTT

20

zigbee2mqtt does seem to have more support for Ikea devices than other mechanisms, however there seem to be notes for each one of them, I think their newer devices work better than the older ones. Here is zigbee2mqtt supported devices list - you can click on each device to read details.
zigbee->mqtt will read the input from the remote and put it on mqtt from there you have to get to the device you are controlling. @mbafford's device driver is specifically for Ecosmart remotes, you will need write a variation of that for ikea remotes or you could bypass that and use node red.

21

I will post my node red flow here once its a little more stable if you want to play with it

23

@anisk & @mbafford
I don't know if you guys have an ST hub running by chance but I have these remotes paired to my ST hub and use SmartThings palette in Node Red to control devices paired to HE with them. Until recently, I was using HubConnect and there was a 1/2 - 2 second delay. Now I am using the ST node that is local using webhooks and it is MUCH faster. It's not always perfect but definitely MUCH better.

It's an option for those who might have already have these remotes paired to ST and are nervous about going to zigbee2mqtt like I was.

1 Like
24

@stephen_nutt Thanks! I do have an older ST sitting around, and I might give that a shot. Running zigbee2mqtt hasn't been bad once I got it set up, but I never did fully integrate the remotes into my system. My enthusiasm for spending the time getting everything working the way I want always seems to die right around "proof of concept completed" stage.

25

ME TOOOOOO!!!!!!!

I bought about 12 of these bulbs for bathrooms so I had 12 remotes. I was only using about 3 previously in locations that it's nice to have but not critical. With the increased reliability and speed bump, I now have about 8 of these remotes around house. When setting up in ST app, you must put the port at the end of your Node Red's IP address. The instructions for the palette do not say that. The palette is node-red-contrib-smartthings.

1 Like
26

@stephen_nutt after running flawlessly for months my usb stick fried. This was a beautiful solution, - had it running with rpi zero w - Don't have any time, energy or desire to debug this or replace the stick, especially after reading that ST integration is working well for people and i have an ST hub somewhere under my bed, so will probably be taking that route. Another thing that kicked in with Covid-19 was ideas of mortality. So I am simplifying and going to stock off the shelf systems that my family can deal with, in case.... I have to do something, I have 10 or so remotes doing nothing stuck on walls everywhere

27

That sucks. I'm about to complete the same gateway to use the newer Ikea dimmer button via zigbee2mqtt. I actually am in the same boat with a growing number of gateways/hubs to overcome HE limitations !

28

Take my experience with a grain of salt though - I went super cheap and got a suspect China stick from amazon - I would like to think that that a legit stick may fare differently. As I said when it worked, it was flawless, snappy milli-secs response. If it wasn't my thinking about mortality, I would have bought a legit stick.