Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Update sonoff.ts] Sane publications interval #7013

Merged
merged 1 commit into from
Feb 4, 2024
Merged

Conversation

enryIT
Copy link
Contributor

@enryIT enryIT commented Feb 4, 2024

Temperature: (endpoint, {min: 30, max: constants.repInterval.MINUTES_5, change: 20}); Record changes:

  • immediately if delta > 0.2°C, at most every 30 seconds
  • always every 5 minutes

Humidity: (endpoint, {min: 30, max: constants.repInterval.MINUTES_5, change: 100}); Record changes:

  • immediately if delta > 1%, at most every 30 seconds
  • always every 5 minutes

Temperature: (endpoint, {min: 30, max: constants.repInterval.MINUTES_5, change: 20});
Record changes:
- immediately if delta > 0.2°C, at most every 30 seconds
- always every 5 minutes

Humidity: (endpoint, {min: 30, max: constants.repInterval.MINUTES_5, change: 100});
Record changes:
- immediately if delta > 1%, at most every 30 seconds
- always every 5 minutes
@Koenkk Koenkk merged commit c52a1cc into Koenkk:master Feb 4, 2024
2 checks passed
@Koenkk
Copy link
Owner

Koenkk commented Feb 4, 2024

Thanks!

@enryIT
Copy link
Contributor Author

enryIT commented Feb 4, 2024

Forgot to mention, I measured a battery usage impact of 15% more than previous intervals over a period of 2 months.
Last year, standard battery duration on SNZB-02 was 18 months, I expect it to last now 16 months.

@StefanGruell
Copy link

Isnt 5 minutes for temp or humidity way too often? Normally this values shouldnt change that fast.

@enryIT
Copy link
Contributor Author

enryIT commented Mar 17, 2024

Isnt 5 minutes for temp or humidity way too often? Normally this values shouldnt change that fast.

The frequency of data transmission from sensors can vary significantly depending on the application's requirements and the environment being monitored.

Transmitting data every 5 minutes provides a high-resolution dataset, this can be critical for applications where understanding minute changes in temperature or humidity is important, such as in precise climate control systems or sensitive processes. High-resolution data allow for better trend analysis and more accurate predictions, also more frequent data transmissions can improve the overall reliability of the monitoring system.

I can agree with you that if you only need to monitor generic temperature changes a 5 minute interval is not needed, and you can agree with me that most users would use this as a sensor for a control system of any form, so a proper populated dataset is needed. The tradeoff here is a mere 15% more battery usage on a average of 18+ months total lifespan.

@StefanGruell
Copy link

...most users would use this as a sensor for a control system of any form...

I can only speak for myself but I use those sensors for monitoring temperatur and humidity outside the house, the cellar and different rooms inside the house. I would love to hear about some examples what systems they are used to find some inspiration.

Transmitting data every 5 minutes provides a high-resolution dataset, this can be critical for applications where understanding minute changes in temperature or humidity is important, such as in precise climate control systems or sensitive processes.

Also correct me if I am wrong, as I am quite new in the Z2M and Zigbee topic, but shouldn't those sensors report change if the change is big enough (see change variable) anyway no matter about the max report interval?

As a final note as you can see I would like to return to the old intervals as they were convenient for my purpose do you have any suggestion or way how I can change that? Cause if I try to change them via the Z2M Reporting tab it will throw me an error.

@enryIT
Copy link
Contributor Author

enryIT commented Mar 17, 2024

...most users would use this as a sensor for a control system of any form...

I can only speak for myself but I use those sensors for monitoring temperatur and humidity outside the house, the cellar and different rooms inside the house. I would love to hear about some examples what systems they are used to find some inspiration.

Well ok, you're monitoring temperature, but what for?
Temperature and humidity sensors can be used to create a comfortable living space, they can trigger HVAC systems to turn on or off, adjust a smart thermostat to maintain optimal conditions, or activate dehumidifiers when necessary. All these applications require a proper dataser that is not achievable with previous update intervals.

Transmitting data every 5 minutes provides a high-resolution dataset, this can be critical for applications where understanding minute changes in temperature or humidity is important, such as in precise climate control systems or sensitive processes.

Also correct me if I am wrong, as I am quite new in the Z2M and Zigbee topic, but shouldn't those sensors report change if the change is big enough (see change variable) anyway no matter about the max report interval?

You're absolutely right, now and with previous settings the senosr would transmit whenever the temperature changes more than 0.2°C, We didn't change this behaviourm we only changes the static transmissions.
With a 5-minute update interval, your system can detect and respond to environmental changes much faster than with hourly updates. This is crucial in environments where temperature and humidity conditions need to be closely managed to prevent damage, ensure comfort, or maintain specific conditions. For instance, if a room's temperature begins to rise due to external factors (like increased sunlight or equipment heat output), a system can quickly adjust heating, ventilation, and air conditioning (HVAC) settings to compensate.
This enables a proactive rather than reactive approach to environmental management.

In both configurations, the key factor is that significant changes (as defined by the 0.2°C threshold) are never missed. This ensures that the system can respond to critical environmental shifts without delay, which is essential for sensitive applications.
With updates every 5 minutes, you gather more data points for minor fluctuations that don't hit the 0.2°C change threshold. This provides a more detailed picture of the environment, which can be crucial for trend analysis, identifying potential issues before they become significant, and making more informed decisions.
The choice between these two configurations depends on the specific needs of your monitoring application. For environments where conditions are relatively stable and only significant changes need immediate action, the hourly update with immediate transmission on a 0.2°C change might suffice. However, for more dynamic environments or applications where detailed trend analysis is crucial, updating every 5 minutes can provide valuable insights and finer control.

As a final note as you can see I would like to return to the old intervals as they were convenient for my purpose do you have any suggestion or way how I can change that? Cause if I try to change them via the Z2M Reporting tab it will throw me an error.

You can manually edit the same file that this commit changed restoring previous values, then restart z2m and maybe re-pair the sensors.

My main question is why would you want to do that, is it really that important to you 1 month worth of battery instead of a more useful dataset?

@StefanGruell
Copy link

StefanGruell commented Mar 17, 2024

Well ok, you're monitoring temperature, but what for?
Temperature and humidity sensors can be used to create a comfortable living space, they can trigger HVAC systems to turn on or off, adjust a smart thermostat to maintain optimal conditions, or activate dehumidifiers when necessary. All these applications require a proper dataser that is not achievable with previous update intervals.

For now I just monitor it to to have an overview of the situation in the house. Especially in the winter to check if the heating system is working correctly or if I have to turn it up manually as its an old non smart device. I do really like your situations especially the last one as I have a dehumidifier myself in the cellar and will try to turn to make it smart with a plug!

You're absolutely right, now and with previous settings the senosr would transmit whenever the temperature changes more than 0.2°C, We didn't change this behaviourm we only changes the static transmissions.
With a 5-minute update interval, your system can detect and respond to environmental changes much faster than with hourly updates. This is crucial in environments where temperature and humidity conditions need to be closely managed to prevent damage, ensure comfort, or maintain specific conditions. For instance, if a room's temperature begins to rise due to external factors (like increased sunlight or equipment heat output), a system can quickly adjust heating, ventilation, and air conditioning (HVAC) settings to compensate.
This enables a proactive rather than reactive approach to environmental management.

I still dont understand why the higher frequency is necessary. I get the higher resolution but why should any setting of device change when the temperatur or humidity doesnt change or changes minimally?

In both configurations, the key factor is that significant changes (as defined by the 0.2°C threshold) are never missed. This ensures that the system can respond to critical environmental shifts without delay, which is essential for sensitive applications.
With updates every 5 minutes, you gather more data points for minor fluctuations that don't hit the 0.2°C change threshold. This provides a more detailed picture of the environment, which can be crucial for trend analysis, identifying potential issues before they become significant, and making more informed decisions.

So if understand that part correct the idea is that we wont miss any changes so more like a fallback if the 0.2°C change is missed somehow? I mean thats correct but are changes below 0.2°C really worth mentioning?

You can manually edit the same file that this commit changed restoring previous values, then restart z2m and maybe re-pair the sensors.

Thanks I will try that.

My main question is why would you want to do that, is it really that important to you 1 month worth of battery instead of a more useful dataset?

Well first of all every day I can safe changing batteries is a win for me (Ofcourse if its 16 or 18 months does not really matter). But my main idea behind this is, I am trying to keep everything as low as possible. Data didnt change? Then there is no need to update. In my opinion this just keeps everything cleaner, starting with the logfiles to data transmission and battery usage. I try to avoid every operation that brings no benefit.

@enryIT
Copy link
Contributor Author

enryIT commented Mar 18, 2024

I still dont understand why the higher frequency is necessary. I get the higher resolution but why should any setting of device change when the temperatur or humidity doesnt change or changes minimally?
...
So if understand that part correct the idea is that we wont miss any changes so more like a fallback if the 0.2°C change is missed somehow? I mean thats correct but are changes below 0.2°C really worth mentioning?

High-frequency updates are not about capturing insignificant changes but ensuring a comprehensive dataset is available for analysis. While changes below 0.2°C might not always warrant immediate action, they can be indicative of trends or issues when analyzed over time. For example, a gradual decrease in temperature over several days could suggest insulation issues or a slowly failing heating system, which might not trigger an immediate alert based on your current threshold settings. A denser dataset offers the foundation for advanced applications, such as PID (Proportional, Integral, Derivative) controllers, which require continuous and detailed environmental data to function optimally.

Well first of all every day I can safe changing batteries is a win for me (Ofcourse if its 16 or 18 months does not really matter). But my main idea behind this is, I am trying to keep everything as low as possible. Data didnt change? Then there is no need to update. In my opinion this just keeps everything cleaner, starting with the logfiles to data transmission and battery usage. I try to avoid every operation that brings no benefit.

Concerns about data cleanliness and overload are valid, however, modern data management tools and techniques can efficiently handle large datasets, allowing for filtering, aggregation, and analysis without becoming cumbersome. The goal is to have data available when needed without necessarily acting on every data point in real time.

Now, addressing the concern about battery life, it's worth noting that many modern sensors are designed to last for months or even years on a single battery charge, even with frequent updates. The difference in battery life between hourly and every 5-minute updates might be less significant than anticipated, especially if the sensor is engineered for low-power operation as this is the case. Moreover, operational efficiency doesn't just stem from minimizing data transmission but from ensuring the right balance between data availability and power consumption.


Just to sum it up, I acknowledge that your approach is not "wrong" as you clearly stated your goals. Home monitoring for general awareness and checking on the efficiency of heating or dehumidifying systems doesn't always require high-frequency updates.

Shifting the data transmission frequency from hourly to every 5 minutes was done to enhance the versatility of environmental monitoring across a wide array of applications. This approach is designed to cater to the diverse needs and usage patterns of the general public, enabling users to not only monitor but also actively manage their environments with greater precision and responsiveness. It's all about laying a foundation that offers flexibility, adaptability, and the potential for growth.

@StefanGruell
Copy link

Thanks a lot for this detailed discussion! I can understand all your points and see why the steps were taking. On a last note as I am using all this for a personal learning experience I am ofcourse trying to change the reporting intervalls to longer periods just to understand the whole system better.

My question would be why a repairing is necessary in this case? Just modifying the js file and restarting Z2M is not sufficient as you stated above but i can not see why. Especially as I updated Z2M to the newest version (1.36.0) every reporting configuration changed without the need of repairing anything.

@enryIT
Copy link
Contributor Author

enryIT commented Mar 25, 2024

I don't really know why, maybe it's because of the specific zigbee implementation by every manufacturer, but some devices blocks zigbee configurations or clusters within some minutes from the first pairing. Sometimes it just works changing the publications intervals on the fly, some other times it just doesn't and you can only force a re-pair in order to properly set new values.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants