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.
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 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.
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.
You are not supposed to have smoke alarms in the bathroom or just outside of a shower bathroom for this reason actually. Also not in the kitchen. A heat detector is recommended for the kitchen.
I had alarms that would go off specifically in the winter in our stair tower because it was a 200 year old house that was renovated badly with no insulation.
Even my Fibaro smart CO alarm got bugged and drained its entire battery in 2 days because it was in a 5-10C environment (within their specs, but they simply lie on the specs).
From my experience, any life saving device simply can’t handle moderately cold temperatures at all, which is honestly extremely ridiculous to me and very dangerous.
Your problem, if dust related would likely be because you are using optical alarms which are easily susceptible to dust. If that is the case, you could try replacing those with ionization alarms on the 2nd floor. Ionization detects flaming fires better and optical detects very smokey fires better.
Try relocating one of the troublesome units to someplace nearby but not mounted to the ceiling. The top of a bedroom dresser, the floor, a bathroom countertop, the top step of the stairs, halfway down the stairs, hanging from a wall (picture hook)… just get creative.
And since you haven’t mentioned it, I presume these are all smoke detectors? Do you have any heat detectors or carbon monoxide detectors installed?
Before areas was a thing in HASS I would name things with an area name. ESP32-5-Bedroom. Now I just leave it what ever it defaults to, then use HASS to name them, and then put them in an area.
How do you et HASS to name them ? i,e. what names does it chose ? So basically you leave the location out of the name as that is shown in the area anyway ? Thing is, that sometimes you need to choose a device from a dropdown, and in these dropdowns they don’t show the area, so having the location sometime gives more information that is missing
@barbarosa
For all those sensors (temp, current etc.) I always prefix the entity ID and friendly name with the area name.
I create areas like “kitchen fridge” or “garage fridge” to keep my stuff organized.
I just tried and I think they are limitations on numerous android OS.
It isn’t exactly a widget but what I have been able to do is create a shortcut when long pressing home assistant app icon on my phone
To do so, go to home assistant app settings/compagnon app/shortcut Give it a name and description, not too short according to documentation (see below), next add under dahsboard
Edit: added another screenshot from settings (sorry in french but that should help). This was just a quick test, this is why I named it assist_widget. You can also change icon type
homeassistant
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.