I don’t think the Zero has enough grunt for HA (unless a very basic system) let alone this component. My Pi4 4Gb on an SSD takes several minutes to reboot.
I’m seeing significant jitter on this sensor (I always have) and usually filter / smooth the readings over a 5 minute window.
Could you implement a filter function - even a simple moving-window would be useful. Yes, I could (and have) created a separate filter sensor but if it was built-in. You wold still have the period, but it would average over the specified window length.
The other thought I have was custom sensor names - could you implement the configuration that would allow a mac address to be associated with a specific sensor name?
It does work very well. I have one sensor that is not reliable for some reason. I have therefore continued to use my original active scanning (on a different Pi) as well.
Currently, data are averaged within one period. That is, the window is equal to the period, but it does not cross the limits of the current period. The number of averaged measurements is returned in the attribute last mean of (or last median of). Theoretically, I can add an option to enlarge the window outside the period (make it a multiple of the period, for example: 2 x periods, 3 x periods). I’ll think it over.
In general, at the very beginning of work on the component, I received several reports on sensors, which sometimes send unusually high or low readings. These values were so different from the current ones that averaging (mean) helped little - use_median option exists to resolve this situation (log_spikes option also useful in some cases).
Could you tell me more about jitter? What do you mean? An unusually sharp measurement spike? What is the typical value of last mean of attribute for this sensor?
It is also worth remembering the delta between the minimum and maximum on the chart - perhaps you have this delta, for example, only 0.5 degrees, and then minor fluctuations may seem large.
As for the names: we discussed this feature on the github, and came to the conclusion that this is an unnecessary complication of the component, since each entity can be easily and conveniently renamed using the standard HomeAssistant tool - Configuration -> Entities:
Hi,
Yes its super basic. I’m just toying with it for now to se what I can actually do before investing more. I dont have any automations yet. I for now would want to see statuses on all of my devices at home using different integrations as I have some sonoffs some smartlife and some smartdgm devices. Also some xiaomi temp sensors so would be good to make them work.
Do I have to enable BLE somehow on Pi zero w with standard hassos instalation?
I’ve downloaded it from here https://github.com/home-assistant/operating-system/releases/download/3.12/hassos_rpi0-w-3.12.img.gz
No, bt-interface is enabled by default.
What is odd is that after a restart this morning
The degree of jitter was different but consistent - not noticed that before I pulled these.
But for me, I really want to smooth this out. 0.1 degree change will cause my heating to cycle.
As I say, my active reading I smooth over a 5 minute window on a 1 minute reporting period.
OK, happy with that; makes sense - might be an idea to add to the docs.
Hah it works, thank you for all the help. It turned out I had a typo in mac instead of F6 I had 6F ;] Now it works great and does not slow down the pi. Weird thing is that it did slow down really bad when it has a typo in mac o.O
1 Like
Your observation about performance degradation is quite valuable - since in the case of a typo in the mac address most of the code is not executed at all (there is no decryption, and there is no further parsing of the packet either, and the component simply proceeds to the next packet) - we have an almost empty cycle that loads processor due to the fact that it works very fast.
In the next release, I will include a small solution that will delay the empty cycle a bit (by 1 millisecond).
Glad everything worked.
The situation described by you is completely normal.
Since the sensor actually sends data every 10 minutes, my component has nothing to work with, there is nothing to average over these time intervals. If, for example, with a period of one minute, I can not average the data by actual measurements, but will do it with the previous value, then I will violate the main principle of the component - to transmit the actual data updates, not “invented” ones. In addition, even if I do, this will not solve your problem, because there will still be a “jitter moment” (“bounce problem”, 20.01 and 20.00, for example) - therefore this is not a solution to your problem and this is not such a simple question as it might seem at first glance.
A typical solution to the bounce problem is to introduce a delay in operation - that is, you need to introduce a delay in automation. Let’s say turn on the heater after the temperature is below 20 degrees for 5 minutes. But such a solution may not always be feasible (for example, in the case of LYWSD03, a delay of at least 10 minutes more is needed), since the additional delay with an already very slow sensor may be unacceptable - this is another aspect because of which I do not like LYWDS03, and like my LYWSDCGQ (20 measurements per minute!). In the case of Home Assistant, you can also use the last triggered automation attribute or an additional timer (as described here, for example).
I am the control engineer in my daily life, and there is a simple and obvious axiom in this area - to control fast process you need a fast sensor!
@macia10 tell me, do you use cooling radiators on your raspberry pi zero? I ask to make sure that thermal throttling does not taking place in your case.
Hi,
Yes I have a radiator and it gets worm in touch. Just measured it and it’s 39,5C. So most likely there is no throttiling going on there. And my power supply is 2A. Also measured it and it draws around 0.3A and 0.1A then idle.
1 Like
OK, thank you
Hi,
I have also something to add here. As I was toying with the sensor yesterday and changing it’s temp reading all the time it refreshed for me every 5min not 10. Could it be something dependent on the FW?
Hmm. Interesting. Perhaps the frequency of measurements sendings depends on the degree of change. But on my sensors, I did not notice this behavior. I have firmware version 1.0.0_0106, hardware B1.4.
Hm, I have the same version so it might be that you are right. I’ve checked records now and some are 5min and some are 10min apart.
Hello! That means you still have the original mitemp_bt component loaded. Follow the instructions carefully - it says HA should be stopped and started and second restart required (installation, step 3). Such double restart required only first time.
Thank you for your guidance. I’ve joined the device. No error has been reported. But I haven’t found the entity in the developer tool. How can I solve this problem? Thank you
The reasons can be very different. To get started, try placing the sensor as close to the HA host as possible to make sure that poor reception is not the reason. Further, I strongly advise you to read our FAQ (especially this part and this one).
In general, more information is needed to deal with any situation. Describe your installation (hardware, software). Turn on debugging for the component and attach HA log lasting 10-15 minutes.
Hi Alexey, thanks for your work. I am already having a NodeMCU esp32 with Esphome for this, but it is just another device to be powered on, hanging around the house. So decided to give a try to your components. After two days of working in parallel, cannot see any reason not stay on this component and to switch off the esp32.
1 Like