Today we are excited to announce our next Works with Home Assistant partner: Third Reality!
Third Reality, Inc. is a smart home products company that has been working with Home Assistant for quite a long time but is now making it official. As a partner, Third Reality and Nabu Casa will be working together to ensure the best experience for connecting Third Reality Zigbee devices to Home Assistant.
Third Reality devices will connect and integrate into Home Assistant easily using the Zigbee Home Automation integration (Zigbee stick required). This means that the devices operate completely locally and state changes coming from the device are instantaneously picked up by Home Assistant. This allows for the best user experience when building a smart home.
Their smart home product portfolio includes switches, motion sensors, door sensors, water leak sensors, plugs, blinds, and newly added buttons. Giving users a full catalog of smart home products. For more information and products about Third Reality, you can visit their website.
If you missed the announcement of the Works with Home Assistant partner program, make sure to check out the blog post.
This is good. But it makes me wonder: what is the Zigbee Alliance for? We’re talking about switches and light bulbs, not uranium enriching devices. If there is already a Zigbee Alliance to bring all of these companies together why aren’t the devices made to automatically work out-of-the-box with ZHA and Z2M and others?
This is not criticism, btw. It’s a genuine question.
Because companies would/could release products and devices, following zigbee guidebook, but implement things differently, and claim “my devices are zigbee compatible”!!
To illustrate, zigbee say:
“The standard offers this switch attribute as either on and off, we also offer this custom attribute for special features”,
… and then some company gets an idea:
“I have a cool idea! I want to offer on-green, on-red, flash-white, and off-black for my light bulbs. So I am going to ignore whatever regular switch and color attribute, and implement everything under the custom umbrella, with an awesome shape of a dragon.”
… and then ZHA and Z2M developers / contributors:
" Aaaaarrrrrrh!" “The dragon lamp is so cool, but why? Why would they do that???” “How many modes are there?? Where’s the documentation???”
(I was exaggerating, or maybe not, but you get the idea.)
Third Reality makes a unique product for light switches that’s great for where you don’t have a neutral or are unwilling to change the switches (such as in a rental):
The only downside is the switch doesn’t support Zigbee groups at all. I emailed when I discovered this and they responded that it was a known limitation.
As an end user it would be great to see Made for Home Assistant consider require these “optional” bits of the Zigbee spec that really are required for a good experience. I only have 2 of these devices, but I can’t help but assume the experience would be very poor in a network with 20 or 30 of these devices for automations like “turn everything off”.
How is this product unique from other zigbee buttons or disconnected switches? Like Aqara, Xiaomi, Ikea and many others? Except that this unique one from Third Reality was not following zigbee standard and was not working so far with non-proprietary gateways…
Edit: I’ve just looked closer at the product - it is indeed unique as it attaches on top of existing (US only) switches. But I would rather consider it a bodge rather than a proper solution… Just like those tiny SwitchBots…
Who do you mean by experts?
Agile approach (icl Scrum and others methods of development) are often simplified by devs to coding only. No docs, no analysis (bussiness, sotware), not testing of own work (let testers do the job) - I’ve obviously saw this attitude, not surprised it exists. Again: mostly those are devs who think that all is not required.
But true experts in the field (ie Scrum coaches etc) confirm that agile methods never request removing any step of development from the pipeline.
Agile is mainly about better methods of communication between parties. shorter release cycles as well as attempts to move specialized roles (stakeholders, analytics, devs of different techs) to single team are tools to achieve better results. there is no word about cannibalize a quality of the product in any way
“We had a fundamental belief that doing it right the first time was going to be easier than having to go back and fix it. And I cannot say strongly enough that the repercussions of that attitude are staggering. I’ve seen them again and again throughout my business life.”
This is an old quote, but tells everything. And things are not documented properly because they are not planned properly and they are continuously a work in progress, because the shorter release times are always more important. Look above as an example the Zigbee switch, its purpose and its capabilities.
Even Zigbee Alliance was not requiring proper documentation for any of the devices to be able to place them in the official product database, not talking about Z-Wave and the changes in the standard which resulted that everyone interpreted differently the standard and created a hot mess.
I hope that Matter will be better, but there are clear signs that it will cause a lot of confusion for end users and compatibility.
I didn’t want to offend you, but IoT is not the place where anything is documented. It is mostly about reverse engineering things to make it possible to control without the stock “well developed” apps.
it’s ok. I agree with what you say. I’m not going to change the world. just cannot agree that incremental/agile work means no care about quality “because it can be fixed in further iterations”.
Shorter iterations means less effort for preps but cannot mean blind devel without preps (exaggerating)
So I’m commenting only on the mentioned “agile” approach.
considering iot: doesn’t it mean that it’s we eho have no access? I assume that DIY home automation (HA obviously belongs too) is mostly relying on reverse engineering. It must no mean that tech docs for particular protocols (often proprietary) do not exist at all.
I’m not following Matter subject closely but recently CEO of Shelly stated, that they will provide matter compatible firmware for their devices, but in this case those devices will not provide internal automation abilities. I was a bit surprised by that. Not that I care: I don’t use automations managed by devices
Many cases where a failsafe required, automations should be managed by the physical devices and should be self sustained if communication fails.
For Shelly, it is probably due to the overhead what Matter requires, and that takes the space and processing power of the ESP module what they use in their devices.
I’ll give them a plug: I’ve been using their motion and contact sensors for awhile. They are very reliable. What I like most is that they use standard AAA batteries that we all probably have a supply of around the home and they last 6-9 months in my motion sensors in very high traffic areas like the kitchen. I suppose if I put lithium instead of alkaline in them they’d go much longer.
I do use them with Zigbee2MQTT and not the built in HA zigbee. In z2m they are fully supported too and have accurate very battery reporting.
Good to see more of this.
this is great to see.