cesarvog wrote:

I ended up choosing a different solution to integrate my growing Zigbee devices into my Indigo control center.
.
Some time ago, I replaced my Hue Bridge with a Dresden-Eletroniks Conbee II Zigbee USB interface.

I'm glad I did it, because it not only has better range than the 2nd gen Hue Hub I was using, but also supports additional Zigbee device types, like switches, sensors,.... It comes with it's own set of software applications: deCONZ is the back-end software that talks to the hardware inside either the Conbee II or the Raspbee II (similar hardware in a Raspberry Pi GPIO interface model). For the front-end, there is the Phoscon App, which is a web based panel that talks to the deCONZ back-end and presents a nice enough interface to interact with the Zigbee devices registered into the Conbee II USB interface, or the Raspbee II GPIO interface.

To try to integrate it with Indigo, I first tried using zigbee2mqtt, therefore bypassing the need for deCONZ entirely. Zigbee2MQTT talked to an MQTT Broker (in my case, Mosquitto), which then is accessed from Indigo by the excellent Indigo MQTT Connector and MQTT Shims plugins (Thanks for both, Joe).

Integration worked fairly well, but I had some difficulty wrapping my head around how to set bulbs RGB color and/or color temp. Once I had each individual bulb set to the desired color (which was done posting msgs on MQTT Explorer) , then I could use Indigo to turn on/turn off, which worked every time, as expected. But later, when I had to replace a bulb, I could not, once again, wrap my head around to the setup specifics...

So thats why I very recently decided to give the Dresden-Eletroniks deCONZ back-end and Phoscon App front-end a new try...

I re-installed deCONZ into the same Raspberry Pi that also supports my z-wave remote interface (via ser2net - exactly like Homeseer's. Z-NET) and that lives hidden in a cupboard in the center of the house. Once it was installed, I installed Homebridge on my Mac to integrate the deCONZ back-end with Apple's HomeKit. It worked right after installation.

The OEM software also allowed me to update the firmware on my Conbee II interface to the latest version, and also to choose a different Zigbee channel for my mesh to work on, thus avoiding 2.4 Ghz channels that could interfere with Wifi.

Then, I reinstalled the Hue Lights Indigo plugin (Thanks, Mr. Sheldon), to integrate Indigo with deCONZ. This was easy, because the deCONZ Rest API is basically the same as the Hue API. The plugin worked right out of the box with the deCONZ back-end!

Next thing was defining Indigo devices for each deCONZ device or groups of devices. From then, I could automate them from Indigo and everything worked exactly as expected.

The Hue Lights plugin obvioulsy does not support every type of Zigbee devices, since it's oriented to the Hue Bridge, which mostly supports devices types also made by Phillips/Signify, but I was able to have the plugin support a few cheap 3 way Zigbee switches I got from an online store, with no difficulty at all. All I had to do was to modify a single text file to include the exact device model, as presented in the Homebridge web panel, or in the Phoscon App.

Knowing myself, I can say that I do intend to get a Hubitat Elevation Hub sometime in the near future. Just to give it a try, as I was bitten by the HomeAutomation fly several years ago... But, for now, I'm a happy camper with the results of integrating my Zigbee based devices into my Indigo system.

For anyone willing to go the deCONZ route, please be aware that, from Indigo to Zigbee devices react instantaneously. On the other hand, let's say I turn on/off a device elsewhere (on the a physical switch for example, or via Homebridge, or Phoscon App, or any of the many other Hue compatible apps existing in the iPhone App Store, then there is a noticeable 2-8 seconds delay for the change to be reflected in Indigo's interface.

That doesn't bother me at all, because I'm used to use Indigo only, whenever I want to control any of my so called "smart" devices, as I see it as my main smart devices control center.

Cesar

Different Computers wrote:

CliveS wrote:

aldera wrote:

I had a lot of trouble getting my head around MQTT.

Me TOO.

In fact, I had so much trouble, and there were so many poor tutorials out there, that I gave up on it.

What I found was all very general or very specific--either "this is why MQTT is great" or "How to attach an Acme Roadrunner Juicer to a T-1000 with a rPi0".

Can you point me at a tutorial that's in between these two? I even got as far as installing Mosquitto on my linux box and it received and sent test commands, but I had NO idea how to proceed from there.

Different Computers wrote:

Can you point me at a tutorial that's in between these two? I even got as far as installing Mosquitto on my linux box and it received and sent test commands, but I had NO idea how to proceed from there.

CliveS wrote:

aldera wrote:

I had a lot of trouble getting my head around MQTT.

aaronlionsheep wrote:

...Forgive me for taking this thread slightly off topic, but what is this UI I see in the background? You have been able to include the Temperature and Humidity (with a beautiful progress bar) in the Device Details. I did some investigating, but I couldn't find your code published anywhere to try and figure out how you did that

Code: Select all

            if type_id == "temperatureSensor":
                if not values_dict.get("uspTemperature", False):
                    error_dict['hubitatDevice'] = u"Hubitat device does not support temperature!"
                else:
                    values_dict["supportsTemperatureReporting"] = True
                    values_dict["NumTemperatureInputs"] = 1
                    if bool(values_dict.get("uspHumidity", False)):
                        values_dict["NumHumidityInputs"] = 1


autolog wrote:

Here is a screen capture of the Hubitat devices in indigo:

Screenshot%202021-02-13%20at%2015.56.09.png (291.84 KiB) Viewed 4368 times

CliveS wrote:

aldera wrote:

Looks like I'll have to do some reading up on the MQTT subject. I don't have any Zigbee devices right now but I noticed that a lot of them are somewhat cheaper now. When I first started playing around with HA, I could have sworn that Zigbee was at least as expensive or even more. Thanks for all the info so far and I'll take a look at the MQTT stuff and see if it's worth it.

Ralph

And remember that MQTT is not just for Zigbee devices, the Shelly devices can use MQTT and they are much cheaper than Fibaro and Aeotec, I have a motorhome with Victron Solar Controller and Shunt which is wired to a Raspberry Pi running Victron software with built in MQTT and Node Red which when on the drive outside can see our WiFi so with Joe's plugins I can now see realtime the volts, current, power, State of Charge of the lithium battery and days left before it is empty, you can also use it to interface with personal weather stations and numerous other devices, which is why it is the standard for IoT interfacing.

BTW, I am no geek whizkid, I cannot code a plugin, my python is basic (very) and I had a lot of trouble getting my head around MQTT (still get confused with Shims), Node Red looks fun but I cannot do much with that either so don't give up, ask here and we all learn a bit more.

siclark wrote:

And read my and Clive's warnings about Aqara sensors. They are cheap and generally work, but are not as reliable as they should be. I have 4 temp sensors and 3 are fine, one is v buggy, but at end of range, and doesnt use repeaters.

Generally though the zigbee hardware, is good and some cheaper options than Zwave, but does show in some cases, but not in a way that impacts performance.

Interestingly though where I have zwave modules on switches for main lights, and zigbee bulbs in lamps all in same room, I constantly see the zigbee bulbs turn on much quicker, 1-2 seconds than the zwave ones.

autolog wrote:

aldera wrote:

DaveL17 wrote:

aldera wrote:

(Sliderules and IBM punch cards were my tools of the day when I went to college in the 60s!)

You and Jon will get along famously, then.

Hmmm... Didn’t think there were too many of us old farts on here. [emoji16]

Started programming using COBOL and Assembler on an IBM 360 mainframe with the aid of coding sheets, flowcharting templates and punched cards.