I don’t think Logitech is any worse than others, but Squeezebox was handled badly and anyone who had one understandably won’t forget about it. I’ve had one of my Harmony Hubs since 2013, which is about when they came out, and they only discontinued them a year ago (maybe two). The CEO was pretty up front about the fact that remotes aren’t profitable, and that they would keep the servers running indefinitely. I optimistically interpret this as “the user base dwindles” or “the servers become security risks”.
I’m hopeful that Broadlink will release an RF remote for the RM4 Pro, which would make it a one-to-one replacement for the Harmony Hub and a very powerful addition to openHAB. As you noted earlier, it’s not convenient to use an app for remote control.
Interesting. It sounds like part of an overall change as people watch more on phones, tablets, and computers, but also that maybe more people are using their phones as remotes, too. I thought I had mentioned this upstream, but the search for a key word or two indicates I haven’t. I don’t like the idea of phones as a remote. A small factor is having to pull it out of my pocket when I’m sprawled on the sofa, but it also means having to put in my passcode or get biometric ID to open it, and then maybe running that app if I had just run a different one (like looking up a show or movie in the IMDB while watching).
It can be useful and helpful to have the remote function on a phone, but I think having a good physical remote that is easy to grab and press a few buttons is often much easier. I hope, between printing a case and buttons and using a Pi Zero wifi with a USB charging connection is something doable.
Exactly - but if they don’t, I like the DIY Pi Zero possibility. (What I’d really like is to have that with an LCD screen, like my Harmony remotes have, to make it easy to add programmable buttons, too.)
I’m glad I’m not the only one that finds an app for remote control can be frustrating.
The web UI allows you to create basic rules, even with conditions, without using scripting languages.
For more complex rules, you can use Blockly, RulesDSL (both are built-in to openhab) or install the automation addon for the other languages, e.g. Jython, JS, Ruby, Groovy, etc. You can install ALL of them and use all of them simultaneously.
The openhab web UI comes with a web based code editor so you can type your Python/JS/Ruby rule code using your browser.
Alternatively, you can create / manage your scripts as files which you can group into subdirectories. In this case, one file can contain multiple rules, so people use this to group similar rules into one file, and similar files into one subdirectory, etc.
I believe the Zigbee stacks firmware proprietary API/CLI specific part is not really a big deal since the Zigbee protocol itself is standardized, so either your application support that API/CLI or it does not, thus that itself does not cause any compatibility issues, buton the other han d Zigbee compatibility between different Zigbee gateway implementations and all Zigbee devices out there are still a serious mess regardless because many manufacturers of Zigbee devices have a tendency to not follow the Zigbee standard specification, (Chinese manufacturers like Tuya and Aqara/Xiaomi is infamous for doing that + Tuya is the worlds largest white-label and OEM/ODM manufacturer of Zigbee devices which gets rebranded to multiple other brands for global resale), which in turn forces all Zigbee gateway implementations to sometimes have to write custom translation/converter handlers with workarounds for each individual device modell that deviate the Zigbee standard specification in order to offer.
Z-Wave solves this by having a common database for each and every device that certified manufacturers get access to, so as long as Z-Wave gateway manufacturers keep importing the latest database and releasing updates + have implemented all different “types” and “features” then any Z-Wave device from all manufacturers should just work in theory (however as we all know theory does not always work in reality, still Z-Wave compatibility is usually great out-of-the-box when compared to Zigbee devices from different brands). think that the new Matter standard (Project CHIP) that uses the Thread protocol uses a similar approach to that(?), which if it is the case could make future Matter over Thread devices compatible with your Matter over Thread implementation if the developer chooses to do so, (but we know from announcements made that many commercial manufacturers, like Philips and IKEA, will still enable propriatory lock down in their own Matter over Thread gateways to only allow users to join/pair/connect their own brand of devices when using their official gateways).
That sounds like, given a choice, for an end user, Z Wave avoids the issue of buying a device and finding out that even though it’s branded Zigbee, that it might not work on your own system.
I don’t remember this clearly, but when I was making my original decision, and this was about 2017, I read that Z Wave also created a mesh network that reduced issues with distance from the source controller. I do remember there was some kind of trade-off for that, but I don’t remember what the downside was to Z Wave at the time (when compared to Zigbee), or at least that I had read about.
It’s worth mentioning here that most of these non-standard Zigbee devices we know are using Zigbee but they do not claim to be Zigbee (i.e. do not bear the Zigbee logo on the box/device). Aquara, Tradfre, Hue, and lot of the rest may claim Zigbee but they usually won’t bear the Zigbee logo on the package. To get the rights to use that logo the device has to be certified by the Zigbee Alliance same as Zwave.
Obviously someone can misuse the logo without permission but they open themselves up to a trademark infringement situation.
So, if the box bears the Zigbee logo, that’s a pretty good indication that it will work just fine out of the box (though there could still be some fly by night outfits that don’t care about the trademark issue). If it just claims to be Zigbee but doesn’t bear the logo, it likely has added stuff above and beyond Zigbee which means it may or may not work.
I’ve stuck strictly to devices that only bear the Zigbee logo on the box and have had no problems with the built in openHAB Zigbee add-on. Granted, I don’t have a ton of Zigbee devices (some smart plugs and a couple of water leak sensors).
People who get a lot of “sort of Zigbee” devices tend to have better luck with ZigbeeToMQTT as that supports more of these not quite Zigbee stuff, but the last I looked it only works with one or two coordinators (and it’s one I don’t have) and in addition you needed to flash the firmware on those to make it work.
So does Zigbee. Both are a mesh network using mains powered devices as routers/repeaters.
For many, Zigbee can be a problem in a congested environment as it uses the same frequencies as WiFi 2g. But that wouldn’t be a problem for you out in the sticks. It’s not even a problem for me in suburbia. But I could see dense environments like apartment complexes could be a different story.
