OK, I'll just keep testing and see how it goes.
When I'm happy that it does not generate false 'sensor lost' flags, then I'll consider making it available.
Welcome to the Cumulus Support forum.
Latest Cumulus MX V4 release 4.4.2 (build 4085) - 12 March 2025
Latest Cumulus MX V3 release 3.28.6 (build 3283) - 21 March 2024
Legacy Cumulus 1 release 1.9.4 (build 1099) - 28 November 2014
(a patch is available for 1.9.4 build 1099 that extends the date range of drop-down menus to 2030)
Download the Software (Cumulus MX / Cumulus 1 and other related items) from the Wiki
If you are posting a new Topic about an error or if you need help PLEASE read this first viewtopic.php?p=164080#p164080
Latest Cumulus MX V4 release 4.4.2 (build 4085) - 12 March 2025
Latest Cumulus MX V3 release 3.28.6 (build 3283) - 21 March 2024
Legacy Cumulus 1 release 1.9.4 (build 1099) - 28 November 2014
(a patch is available for 1.9.4 build 1099 that extends the date range of drop-down menus to 2030)
Download the Software (Cumulus MX / Cumulus 1 and other related items) from the Wiki
If you are posting a new Topic about an error or if you need help PLEASE read this first viewtopic.php?p=164080#p164080
Cumulus behaviour when sensor contact lost
-
BCJKiwi
- Posts: 1259
- Joined: Mon 09 Jul 2012 8:40 pm
- Weather Station: Davis VP2 Cabled
- Operating System: Windows 10 Pro
- Location: Auckland, New Zealand
- Contact:
Re: Cumulus behaviour when sensor contact lost
Update.
After a lot of fiddling and changes I have been running an algorithm which stores the last 5 <#temp> <#hum> <#dew> <#rmidnight> <#wlatest> <#bearing> values at every interval which is 10 mins in the test setup.
The routine has been comparing the current sum of these variables with the sum from 30 minutes before. If the sum is the same then the sensorlost var is set to 1.
The logs show that in the last 19 days with data logged every 10 minutes, there have been 14 sensor lost indications.
The primary issue is the obvious one - when it is calm there is not enough variation in the sensor returned data to always return a difference in the sum.
There are a few ways the tests could be changed;
1. compare each of the values individually rather than the sum
2. compare more than one of the current and stored sets.
I feel it is unlikely to be a reliable technique in the long term.
However, since I have all this working, I will try adding some different comparison techniques and see what the outcome is.
After a lot of fiddling and changes I have been running an algorithm which stores the last 5 <#temp> <#hum> <#dew> <#rmidnight> <#wlatest> <#bearing> values at every interval which is 10 mins in the test setup.
The routine has been comparing the current sum of these variables with the sum from 30 minutes before. If the sum is the same then the sensorlost var is set to 1.
The logs show that in the last 19 days with data logged every 10 minutes, there have been 14 sensor lost indications.
The primary issue is the obvious one - when it is calm there is not enough variation in the sensor returned data to always return a difference in the sum.
There are a few ways the tests could be changed;
1. compare each of the values individually rather than the sum
2. compare more than one of the current and stored sets.
I feel it is unlikely to be a reliable technique in the long term.
However, since I have all this working, I will try adding some different comparison techniques and see what the outcome is.