I have the same problem with a zwave energy meter that randomly send a single reading of multiple gigawatts. This makes the history unusable until I manually delete those data points. I haven’t noticed this problem with any of my zigbee sensors.
I am in no way defending their behavior, but API calls will always incur some cost - either in backend resource consumption with “paying” customers, or legitimate costs if they’re relying on AWS infrastructure.
However, like the whole reddit debacle, API usage isn’t always well optimized at the client end, and it can become a negotiation rather than a C&D…unless you’re looking to make a competitor as well.
A few thoughts come to mind… 1) Some of their customers may only be customers because of HA compatibility. 2) HA does not require a cloud API to function - a LAN based solution is usually preferred anyway. 3) There are far more diplomatic ways to approach this issue.
To think, from a business perspective, that any notable portion of their userbase bought the devices with the explicit expectation that it would work with HA would be naive. We’re hobbyists, a niche market, the less-than-1% of their market evaluations. Losing those customers while reducing whatever burden or cost they’re incurring is probably worth it.
HA doesn’t - but while I don’t have any Haier equipment to say, the other smart devices in my house which aren’t either esphome or tasmota don’t connect locally to my devices, but to the vendor cloud API. Ecobee, Wyze, Traeger all do that instead.
Totally agreed. I think AWS API costs are a few cents to the thousand, so a discussion with the developer about the use would be the nice way instead of just kowtowing to the bean counters.
My argument to that would be if we are only a niche segment then where is the serious economic harm they are referring to? It sounds to me like API calls are happening either way but they don’t want to lose out on the ad and customer tracking revenue. Also, I as other have pointed out there is no reason it needs a remote cloud to change the thermostat.
It could be a case of disproportionate impact - consider that forecasting within Haier for their cloud API would probably be based upon X number of units in the field and Y number of average API calls per unit/user/premises. At 40,000 units in the field at 1000 calls per day (which they know because they designed the software, or at least had a hand in resourcing discussions), you have 40,000,000 calls per day.
If you have some third party app which is generating 4,000,000 calls by itself, and you see only 400 users doing this, then it’s a simple high usage target to hit.
Ad revenue, maybe. Tracking is still possible because it’s the same device, and if there’s any security at all, they’ll still have all the native API stuff they’d normally get, temperatures, weather, occupancy, etc.
I will say at a brief glance at the repo for the project that there’s some calls which imply it would get the local IP for the device, and may from there be able to issue calls direct to the device. That would make me think there’s only a few calls to their cloud to establish a relationship and product info, so the disproportionate load theory, barring bugs, doesn’t hold up. While it’s been a good brain exercise, we’ll be left guessing, and hoping Haier decides to be better.
This is fairly common with remote sensors. Some are perfect and exist in a perfect system, some do not. I am going to rattle off some of the first things that pop into my head…
Honestly, there are a thousand reasons that you could miss a data point every once in a while. Just looking at the chart, it is still sending a data block but the humidity just reported low for a second. Maybe the thermostat is not getting a data block and filling in the data based on its own clock.
Compare it to other data and see if the system turned on or off. Electronics can be sensitive to power drops and it wasn’t able to feed power to the part of the board that manages the sensor for a second. Maybe there is a condition where a capacitor gets fully discharged for a second and is pulling all current away from the sensor. (It’s usually an analog signal from sensors and maybe a measurement of resistance that translates to temperature or humidity. A voltage drop would significantly impact a reading.)
It could be a timing glitch with the code where it can’t read the sensor but builds the data block anyway. Depending on how the sensor works, it could be trying to compute the data the second it gets polled for data and it has nothing to give.
It could even be the wiring to the rest of the system. HVAC systems vibrate and a screw might be getting loose. It could be a cold solder joint, even. What is to commonality between the two thermostats that you had?
The list goes on. I have always treated sensor data as unreliable. Heck, I have a couple of CO2 sensors that do the same this as what you are seeing here. Every so often, the just report zero for a second.
Mesh protocols like zwave and zigbee aren’t 100% reliable. It could be local interference with the signal.
Without some extensive debugging and the willingness to disassemble your thermostat, just treat it as an annoyance.
I don’t but I have a couple of the presence sensors from the company and like them a lot. They sort of require some tuning but have been quite reliable since.
I’ve got a Qingping Air Monitor Lite - it’s small, not ugly, and from what I read at the time, has a decent CO2 sensor. It integrates perfectly with Home Assistant via Bluetooth. Seriously, no issues once I got it setup - which I believe did require their app to do initial setup/updates/etc… www.home-assistant.io/integrations/qingping/www.amazon.ca/…/B092HK4BB1
I have a ‘roll-your-own’ using an adafruit SCD-30 module www.adafruit.com/product/4867 IR-based CO2, temp & humidity; I2C with python libraries, so integrating it with an RPi is easy. Sensor is self-calibrating over time, so if you leave it in a higher CO2 space with no exposure to fresh air, it will eventually drift such that the lowest observed CO2 reports as 420 ppm. Newer SCD-40 is only $45, but different sensor technology.
I have done 3 and 4, and I definitely prefer the air gradient, it is a nice sleek little box that is flashable with esphome making it tie directly into HASS. Will be getting more of them in the near future.
homeassistant
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.