Welcome to the Cumulus Support forum.

Latest Cumulus MX V3 release 3.28.6 (build 3283) - 21 March 2024

Cumulus MX V4 beta test release 4.0.0 (build 4018) - 28 March 2024

Legacy Cumulus 1 release v1.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

Extra sensor handling

Please DO NOT use this to publish your entire wish. This Forum is for specific suggestions to enhance the usability of Cumulus MX for all users, NOT your personal requirements. Please check this forum and the rejected forum to make sure you are NOT posting a DUPLICATE suggestion. It will be heavily monitored by Admin and Mark Crossley to determine the feasibility and the difficulty of the suggestion. Those Topics that are deemed inadmissible will moved to the rejected Forum. The remaining Topics will be the Accepted list of future developments, and when our voluntary development group adds it to a build, the build number will be added to the Topic title.
Post Reply
User avatar
HansR
Posts: 5871
Joined: Sat 20 Oct 2012 6:53 am
Weather Station: GW1100 (WS80/WH40)
Operating System: Raspberry OS/Bullseye
Location: Wagenborgen (NL)
Contact:

Extra sensor handling

Post by HansR »

Originally discussed here.

Now that the Ecowitt sensor environment can be added as extra sensor to Davis a question comes to mind as to what is the primary sensor (of a certain type). Apparently the world is moving towards easy configurable sensors so it seems logical to modify CMX towards that trend.

I would like to suggest to make it possible to select - for each type of sensor - which should be used as primary sensor, the primary sensors being logged in the standard logfiles, the other sensors being logged to the extra sensor file. It would be nice to have a per sensor unique indicator whether the sensor is active or not and not to have to determine that by circumstantial evidence. If a primary sensor is set inactive, if the is another sensor of that type it would become the primary automatically.

Effectively, though the weather station remains the basis of CMX, this would make it possible to have an array of sensors of which you can choose which ones should comprise your primary weather sensors and which should be secondary and change that configuration on the fly. Apart from having multiple sensors it would be easy to make repairs/maintenance to a sensor without skipping measurements.

I understand this is a major move and would like to hear what others think about this suggestion to give Mark an idea whether he should or should not move in this direction.
Hans

https://meteo-wagenborgen.nl
CMX build 4017+ ● RPi 3B+ ● Raspbian Linux 6.1.21-v7+ armv7l ● dotnet 8.0.3
User avatar
mcrossley
Posts: 12694
Joined: Thu 07 Jan 2010 9:44 pm
Weather Station: Davis VP2/WLL
Operating System: Bullseye Lite rPi
Location: Wilmslow, Cheshire, UK
Contact:

Re: Extra sensor handling

Post by mcrossley »

As sfws pointed out you can do this for temperature sensors on OS stations.

Implementing it for a single station with a limited number of sensors is not hard, but doing generically across different station types is harder. Then doing it generically across station types with additional sensors from another station is another step. It would need a bit of planning, and how it would work with existing implementations.

For instance the Davis WLL station already allows you to select which transmitter to use as primary for wind, rain, t/h, solar and UV. But it does not allow you to select any of the extra t/h sensors, or even an AirLink for primary t/h.

I think the possible combinations of different sensors will be the issue to a generic solution?
User avatar
HansR
Posts: 5871
Joined: Sat 20 Oct 2012 6:53 am
Weather Station: GW1100 (WS80/WH40)
Operating System: Raspberry OS/Bullseye
Location: Wagenborgen (NL)
Contact:

Re: Extra sensor handling

Post by HansR »

mcrossley wrote: Sat 07 Aug 2021 5:28 pm I think the possible combinations of different sensors will be the issue to a generic solution?
I think if the number of combinations is a problem the solution is not generic and it may be better not to start the exercise because hardware will change and be added as we have seen the last years (that actually is at the origin of this question). I don't think this should be done on a per device basis.

I assume it requires an additional (logical/translational) layer where you can change the physical devices to logical devices e.g. the user sees only T sensors and assigns one to the primary. The default primary would be that of the base weather station. The other sensors will be extra sensors. So basically you just need two arrays one of the available sensors and one with the assignments. All sensors are read just like normal but the value passed to the upper layer and storage/history will be modified by the assignment layer. That would be my basic idea. So the source of the T would become irrelevant for the calculations, history, rollover and whatever else is done with the values. It would be a fairly low level change.

I'll look into the code and if I get some definite ideas I'll talk to you off-line but I assume it requires diving into the station/sensor drivers and the logic around it.
I never looked into that so it may take some time (if I don't drown in it :) )
Last edited by HansR on Sun 08 Aug 2021 7:28 am, edited 1 time in total.
Hans

https://meteo-wagenborgen.nl
CMX build 4017+ ● RPi 3B+ ● Raspbian Linux 6.1.21-v7+ armv7l ● dotnet 8.0.3
Phil23
Posts: 884
Joined: Sat 16 Jul 2016 11:59 pm
Weather Station: Davis VP2+ & GW1000 (Standalone)
Operating System: Win10 Pro / rPi Buster
Location: Australia

Re: Extra sensor handling

Post by Phil23 »

The other thing I'm curious about is the use of the Custom Server Upload in the Console or GW1000 works in a manner where the Ecowiit device pushes it's data to the CMX API.
That's correct?

So that would also dictate that the update times are not hard defined as 10:00, 10:10, 10:20 etc,
Assume they would be more like it see in the EW environment where time stamps a related to probably a boot time & can be 10:03, 10:13 etc.

That would be avoided if the EW as extra was read the same way as when it's the primary station, where CMX pulls the data.

This also opens the next issue, my GW1000 is currently read by two CMX installs, so at 10:00am it gets hit with two request.
If my Davis install did a data request as well the GW would be hit with 3 requests.....

While I haven't noticed any issues with simultaneous request, I gather the could be the case where the requests collide.

The ability of being able to run multiple CMX instances on different devices is the one thing I love the most about the GW1000 is this, makes for very easy test installs to try changes without mucking up a main install

Cheers.
:Now: :Today/Yesterday:

Image

Main Station Davis VP2+ Running Via Win10 Pro.
Secondary Stations, Ecowitt HP2551/GW1000 Via rPi 3 & 4 Running Buster GUI.
:Local Inverell Ecowitt Station: :Remote Ashford Ecowitt Station:
User avatar
HansR
Posts: 5871
Joined: Sat 20 Oct 2012 6:53 am
Weather Station: GW1100 (WS80/WH40)
Operating System: Raspberry OS/Bullseye
Location: Wagenborgen (NL)
Contact:

Re: Extra sensor handling

Post by HansR »

Phil23 wrote: Sat 07 Aug 2021 11:06 pm The other thing I'm curious about is the use of the Custom Server Upload in the Console or GW1000 works in a manner where the Ecowiit device pushes it's data to the CMX API.
That's correct?

So that would also dictate that the update times are not hard defined as 10:00, 10:10, 10:20 etc,
Assume they would be more like it see in the EW environment where time stamps a related to probably a boot time & can be 10:03, 10:13 etc.
That depends on when CMX is ready to receive. If CMX dictates reception frequency by asking GW then Ecowitt can push what it wants but it may disappear in the black hole.
But I leave that to Mark.
Phil23 wrote: Sat 07 Aug 2021 11:06 pm This also opens the next issue, my GW1000 is currently read by two CMX installs, so at 10:00am it gets hit with two request.
If my Davis install did a data request as well the GW would be hit with 3 requests.....

While I haven't noticed any issues with simultaneous request, I gather the could be the case where the requests collide.
True simultaneous requests - a request arrives when a previous request is still being handled - from CMX to the GW for the same device are not likely to happen. And if they do the worst that can happen is that your request gets lost (which would be bad work by the GW btw) in which case CMX probably times out. No doubt Mark can give an even more detailed answer.

Anyway I don't think device responsiveness / failure handling has anything to do with the question for the primary sensor which I think only has to do with a translation between physical and logical sensors.
Hans

https://meteo-wagenborgen.nl
CMX build 4017+ ● RPi 3B+ ● Raspbian Linux 6.1.21-v7+ armv7l ● dotnet 8.0.3
Phil23
Posts: 884
Joined: Sat 16 Jul 2016 11:59 pm
Weather Station: Davis VP2+ & GW1000 (Standalone)
Operating System: Win10 Pro / rPi Buster
Location: Australia

Re: Extra sensor handling

Post by Phil23 »

True,
I got OT regards the other EW matters.

From an end user point of view it sounds simple.

Just a list of use alternate sensor option for all of the primary's, then an options to choose from the Extras available.
And then they may come & go a bit.

These issues are very easily solved when you are NOT the one writing the code.....
:Now: :Today/Yesterday:

Image

Main Station Davis VP2+ Running Via Win10 Pro.
Secondary Stations, Ecowitt HP2551/GW1000 Via rPi 3 & 4 Running Buster GUI.
:Local Inverell Ecowitt Station: :Remote Ashford Ecowitt Station:
Post Reply