[Release] zigbee2mqtt EcoSmart Remote ZBT-CCTSwitch-D0001

⚙️ Custom Apps and Drivers
1

Starting a new thread due to substantial amount of cross-talk on the original Zigbee 3.0 button controller $8.88 USD at home Depot, includes cct bulb - #106 by mbafford

Since there's likely not going to be direct support for these remotes as they use group messaging to the Hub and Hubitat has no plans at this time of supporting that, we have to fall back to zigbee2mqtt or possibly SmartThings or Home Assistant to support this device in Hubitat. This release supports zigbee2mqtt.

Getting off the ground with zigbee2mqtt is out of the scope of this document, but following the instructions on the zigbee2mqtt website should get you started. Read the first three Getting Started links to make sure setting up zigbee2mqtt is something you're comfortable with.

To get support for the EcoSmart remotes on Hubitat:

  1. [Linux/Windows/etc] Get zigbee2mqtt up and running
  2. [Linux/Windows/etc] Patch zigbee2mqtt with the driver code - there are two accepted pull requests for this - so depending on when you read this you may need to apply these PRs manually or you may have support out of the box:
    https://github.com/Koenkk/zigbee-herdsman/pull/109
    https://github.com/Koenkk/zigbee-herdsman-converters/pull/822
  3. [Linux/Windows/etc] Install my device driver code to monitor mqtt and translate the zigbee2mqtt messgaes into Hubitat events:
    https://github.com/mbafford/hubitat-integration-code/blob/master/Drivers/EcoSmart_Remote_Zigbee2MQTT/ecosmart_remote_from_zigbee2mqtt.groovy
  4. [Hubitat] Install the device handler with the above driver by creating a Virtual Device and selecting this device handler as the Type:
    image
    image714×500 12.3 KB
  5. [Hubitat] Configure the device with your mqtt details:
    image
    image993×555 16.3 KB
  6. [Hubitat] Test the device and monitor events:
    image
    image1031×580 30.4 KB
  7. [Hubitat] Configure rules (e.g. Hubitat Simple Lighting)
    image
    image677×981 22.9 KB

I've only tested this integration for the last couple of days, but at this point it seems very viable and very responsive when connected. Long term stability is an unknown - it does look like I'll need to add reconnect logic for mqtt - the built-in driver doesn't seem to reconnect, putting the driver in limbo if connection is lost. Hopefully someone else has a pointer to a stable mqtt driver that survives disconnects to pull this all together.

Like everything with Hubitat, documentation for the mqtt driver is minimal and mainly relies on community code. So what I pieced together is heavily inspired by others kind enough to share on github. Also, this thread: MQTT Client - Beta - #43 by kevin

2 Likes
2

very nice - what is the minimum hardware I would need to get for this? Do I need the debugger and the cable or is the sniffer enough?

3

Depends on your comfort level - please make sure you read the "Getting started" pages of https://www.zigbee2mqtt.io/. Multiple flashing options are outlined there. I honestly don't understand why they lead with the CC Debugger option, since Raspberry Pi / Arduino is simple, so make sure you check out the " Alternative flashing methods" section under flashing.

I was able to flash the CC2531 dongle using just this kit, some jumper wires I already had, and a Raspberry Pi:

If you have connectors/jumper wires small enough for the micro pitch header on the USB dongle, then you can flash this entirely with a Raspberry Pi and the dongle.

Once flashed, a Raspberry Pi Zero W(ireless), the dongle, and a MicroUSB OTG adapter are all you need. Or a regular Raspberry Pi and no USB adapter is needed.

1 Like
4

thanks - thats more affordable, just ordered it.

what sort of CPU usage does this have? I have a pi 1 B+ which has the same cpu as zero w, it runs a couple of homebridge instances and a nodered server. Wonder if I can put this on it?

6

Have you looked at this thread? there is some sample code in there -

7

I got the remote running using the latest_dev docker image for Zigbee2MQTT. I did have to tweak the driver code switch statement:

case "button_1": button = 1; break;
case "button_2": button = 2; break;
case "button_3": button = 3; break;
case "button_4": button = 4; break;

I added the underscore.

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