Fabio Manganiello on Nostr: A reminder that you should never, ever trust #IoT companies, unless they have a ...
A reminder that you should never, ever trust #IoT companies, unless they have a proven record of working with open standards and being developer-friendly.
A few weeks ago I did some renovation work in my bathroom, and I had a chance of upgrading my smart lights (from one single Hue bulb to 5 color spotlights).
Unfortunately, Hue wasn’t an option this time - we lowered the ceiling to fit the new pipes, and since Hue spotlights are quite bulgy installing them would have meant losing 3-4 more cm of ceiling height.
So after some quick research with the contractor we opted for a bunch of #Tuya lights, which were the only smart spotlights flat enough to fit into our space constraints.
Connecting them to Platypush was already painful. No ZigBee/Z-Wave/Bluetooth. Each of those lights is basically an embedded Linux system that communicates over WiFi with its own proprietary protocol, and with the mobile app acting as a virtual bridge (what a waste of computing power, IP addresses and cognitive burden of learning a new protocol for something that has already been solved many times over by ZigBee). There is a way of communicating directly to the device over WiFi, but it’s mainly thanks to reverse engineering efforts whose mileage may vary (depending on model and firmware version). And those usually require a Tuya API key (something that I haven’t yet managed to put my hands on, because their developer website is slow, buggy and prone to sudden crashes, and getting a developer account involves jumping through lots of bureaucratic hurdles being a Chinese-owned company).
So I’ve resorted to a workaround - at least these lights work with Google Assistant, so I’m sending text queries to the assistant over the old API whenever I want to control them. Suboptimal, slow (1-2 secs before the lights change state), but at least it works.
Now this.
If I want to keep using the smart features of the lights that I’ve regularly purchased, I need to pay for a subscription. Why? And why wasn’t this made clear in big capital letters on the product description as well - like this product has a trial period of 30 days and then it requires a subscription to keep functioning?
Luckily it seems that the subscription is required only for business accounts (not sure how they’re going to enforce it or even check it though). But I know that in this kind of business models things are always one step away from a shitty PM taking aggressive “revenue stream decisions”, and pushing a software update to all lights that requires a paid subscription from everyone. And customers have no way of knowing that in advance - except when one morning they enter the bathroom to brush their teeth before work, and the lights suddenly don’t work anymore.
A few weeks ago I did some renovation work in my bathroom, and I had a chance of upgrading my smart lights (from one single Hue bulb to 5 color spotlights).
Unfortunately, Hue wasn’t an option this time - we lowered the ceiling to fit the new pipes, and since Hue spotlights are quite bulgy installing them would have meant losing 3-4 more cm of ceiling height.
So after some quick research with the contractor we opted for a bunch of #Tuya lights, which were the only smart spotlights flat enough to fit into our space constraints.
Connecting them to Platypush was already painful. No ZigBee/Z-Wave/Bluetooth. Each of those lights is basically an embedded Linux system that communicates over WiFi with its own proprietary protocol, and with the mobile app acting as a virtual bridge (what a waste of computing power, IP addresses and cognitive burden of learning a new protocol for something that has already been solved many times over by ZigBee). There is a way of communicating directly to the device over WiFi, but it’s mainly thanks to reverse engineering efforts whose mileage may vary (depending on model and firmware version). And those usually require a Tuya API key (something that I haven’t yet managed to put my hands on, because their developer website is slow, buggy and prone to sudden crashes, and getting a developer account involves jumping through lots of bureaucratic hurdles being a Chinese-owned company).
So I’ve resorted to a workaround - at least these lights work with Google Assistant, so I’m sending text queries to the assistant over the old API whenever I want to control them. Suboptimal, slow (1-2 secs before the lights change state), but at least it works.
Now this.
If I want to keep using the smart features of the lights that I’ve regularly purchased, I need to pay for a subscription. Why? And why wasn’t this made clear in big capital letters on the product description as well - like this product has a trial period of 30 days and then it requires a subscription to keep functioning?
Luckily it seems that the subscription is required only for business accounts (not sure how they’re going to enforce it or even check it though). But I know that in this kind of business models things are always one step away from a shitty PM taking aggressive “revenue stream decisions”, and pushing a software update to all lights that requires a paid subscription from everyone. And customers have no way of knowing that in advance - except when one morning they enter the bathroom to brush their teeth before work, and the lights suddenly don’t work anymore.
