Yesterday Rain

[PaulMy]

Hi,

Code: Select all

It appears my WL pro account stopped logging data since July 16th. I have emailed them.

Hopefully Davis can get that resolved. I have found WLL device and upload to WL.com to be very reliable, even when the local power is out and no internet service the WLL uploads logged data to WL.com when internet is restored.

I don't get the "2024-08-01 08:22:00 - *** Data input appears to have stopped" message like you do in my CMX/WLL but get those in my CMX/WiFilogger and I think this is due to the CMX disconnect period to allow WiFiLogger to do its other uploads.

Enjoy,
Paul

[mcrossley]

I'm surprised WiFi logger needs a disconnect. The Davis logger does because it can only handle a single network connection at once, I'd have thought a more modern device like the WiFi logger would not have that restriction.

Anyway, you can check the cause by enabling debug - do the data stopped happen during a disconnect period? I'd have thought it unlikely since the disconnects are normally of the order of seconds, and the data stopped timeout is 1 minute.

It's probably just the WiFi logger flakiness - it's not my favourite device!

[PaulMy]

Hi Mark,

'm surprised WiFi logger needs a disconnect. The Davis logger does because it can only handle a single network connection at once, I'd have thought a more modern device like the WiFi logger would not have that restriction.

Anyway, you can check the cause by enabling debug - do the data stopped happen during a disconnect period? I'd have thought it unlikely since the disconnects are normally of the order of seconds, and the data stopped timeout is 1 minute.

It's probably just the WiFi logger flakiness - it's not my favourite device!

The WiFiLogger is much like the WeatherlinkIP logger except it has additional features to upload to various weather services like WOW CWOP AWEKAS etc., in addition to uploading to Weatherlink.com the same as the WeatherlinkIP or WeatjherlinkPC (one the reasons I keep it running as I can't run my WeatherlinkPC 24/7). In the initial testing of WiFiLogger we were advised to use the CU disconnect settings to also allow WFL to do its uploads to Weatherlink.com and the others. I have experimented with several disconnect settings from very long to short and now back at 10 seconds. The WL.com account was originally setup for and uploaded by my WeatherlinkPC software and I understand is the API Token V1. When I got the WFL in 2018 I just continued to update to that WL.com account. This is the WL.com account I have used when the CMX/Davis Cloud (VP2) station type was added. However, in trying to make CMX Davis Cloud source working I need to use the API V2 settings.

The CMX/WFL install works quite well but does have its error periods. Sometimes quite a few in succession and other times an hour or more apart.

Code: Select all

2024-08-02 11:12:41 - LOOP: 14 - Expected data not received, expected 99 bytes, got 0
2024-08-02 11:11:40 - WakeVP: *** Console Not woken
2024-08-02 11:04:51 - LOOP: 18 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:51:00 - LOOP: 24 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:50:50 - LOOP: 19 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:50:20 - LOOP: 4 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:49:50 - LOOP: 19 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:49:00 - LOOP: 24 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:48:50 - LOOP: 19 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:48:40 - LOOP: 14 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:48:30 - LOOP: 9 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:48:00 - LOOP: 24 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:47:31 - LOOP: 9 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:47:01 - LOOP: 24 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:46:51 - LOOP: 19 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:46:01 - LOOP: 24 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:45:51 - LOOP: 19 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:45:41 - LOOP: 14 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:45:01 - LOOP: 24 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:44:51 - LOOP: 19 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:44:41 - LOOP: 14 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:44:31 - LOOP: 9 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:44:21 - LOOP: 4 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:44:01 - LOOP: 24 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:43:51 - LOOP: 19 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:43:30 - LOOP: 9 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:42:50 - LOOP: 18 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:42:40 - LOOP: 13 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:42:30 - LOOP: 8 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:40:50 - LOOP: 18 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:40:40 - LOOP: 13 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:40:30 - LOOP: 8 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:39:30 - LOOP: 8 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:36:00 - LOOP: 24 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:35:00 - LOOP: 24 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:13:30 - LOOP: 9 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:13:20 - LOOP: 4 - Expected data not received, expected 99 bytes, got 0
2024-08-02 10:13:00 - LOOP: 23 - Expected data not received, expected 99 bytes, got 0
2024-08-02 08:46:00 - *** Data input appears to have stopped
2024-08-02 08:45:00 - *** Data input appears to have stopped
2024-08-02 08:44:00 - *** Data input appears to have stopped
2024-08-02 08:43:00 - This Cumulus MX instance appears to be running a test version. This build=4027, latest available build=4027
2024-08-02 08:36:00 - *** Data input appears to have stopped
2024-08-02 08:35:00 - *** Data input appears to have stopped
2024-08-02 07:02:42 - OpenTcpPort: Error - No connection could be made because the target machine actively refused it. 10.0.0.166:22222
2024-08-02 07:02:39 - OpenTcpPort: Error - No connection could be made because the target machine actively refused it. 10.0.0.166:22222
2024-08-02 07:02:36 - OpenTcpPort: Error - No connection could be made because the target machine actively refused it. 10.0.0.166:22222
2024-08-02 07:02:29 - OpenTcpPort: Error - No connection could be made because the target machine actively refused it. 10.0.0.166:22222
2024-08-02 07:02:27 - SendLoopCommand: Error sending LOOP command [LPS 2 1]: Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host..
2024-08-02 07:02:26 - LOOP: Timed out waiting for LOOP data

I have looked at these errors and the MXdiags at the same time but a little overwhelming for me. I have debug logging always enabled.

No need to spend any time on this Mark. And I keep it running and uploading to my Weatherlink.com basic account to keep that data going, and also to do some testing like the CMX Cloud (VP2) station.

Enjoy,
Paul

[kj6rgx]

2024-08-02 16:30:49.038 DecodeAlCurrent: Outdoor - Found AirLink data
2024-08-02 16:30:49.038 DecodeAlCurrent: Outdoor - Using temp/hum data
2024-08-02 16:31:00.255 *** Data input appears to have stopped
2024-08-02 16:31:14.255 GetCurrent: Get WL.com Current Data
2024-08-02 16:31:14.255 GetWlCurrent: Downloading Current Data from weatherlink.com
2024-08-02 16:31:14.255 WeatherLink URL = https://api.weatherlink.com/v2/current/ ... ey=API_KEY
2024-08-02 16:31:14.315 GetCurrent: WeatherLink API Current Response code: 200
2024-08-02 16:31:14.315 GetCurrent: WeatherLink API Current Response: {"station_id":129742,"station_id_uuid":"11e2454b-a38b-4453-8b13-eb6ecd41527d","sensors":[{"lsid":488358,"sensor_type":48,"data_structure_type":2,"data":[{"ts":1722630651,"tz_offset":-14400,"bar_trend":-20,"bar":29.918,"temp_in":70.4,"hum_in":66,"temp_out":73.4,"wind_speed":2,"wind_speed_10_min_avg":3,"wind_dir":31,"temp_extra_1":null,"temp_extra_2":null,"temp_extra_3":null,"temp_extra_4":null,"temp_extra_5":null,"temp_extra_6":null,"temp_extra_7":null,"temp_soil_1":null,"temp_soil_2":null,"temp_soil_3":null,"temp_soil_4":null,"temp_leaf_1":null,"temp_leaf_2":null,"temp_leaf_3":null,"temp_leaf_4":null,"hum_out":91,"hum_extra_1":null,"hum_extra_2":null,"hum_extra_3":null,"hum_extra_4":null,"hum_extra_5":null,"hum_extra_6":null,"hum_extra_7":null,"rain_rate_clicks":0,"rain_rate_in":0,"rain_rate_mm":0,"uv":null,"solar_rad":null,"rain_storm_clicks":62,"rain_storm_in":0.62,"rain_storm_mm":15.748,"rain_storm_start_date":1722571200,"rain_day_clicks":62,"rain_day_in":0.62,"rain_day_mm":15.748,"rain_month_clicks":62,"rain_month_in":0.62,"rain_month_mm":15.748,"rain_year_clicks":2587,"rain_year_in":25.87,"rain_year_mm":657.098,"et_day":0,"et_month":0,"et_year":0,"moist_soil_1":null,"moist_soil_2":null,"moist_soil_3":null,"moist_soil_4":null,"wet_leaf_1":null,"wet_leaf_2":null,"wet_leaf_3":null,"wet_leaf_4":0,"forecast_rule":45,"forecast_desc":"Increasing clouds with little temperature change.","dew_point":71,"heat_index":76,"wind_chill":73,"wind_gust_10_min":6}]}],"generated_at":1722630674}
2024-08-02 16:31:14.315 GetCurrent: Found 1 sensors to process
2024-08-02 16:31:14.316 DecodeCurrent: Using this record type 2

Looks like it found data to me...why would the error show up in the log before retrieving current data?

[mcrossley]

The check for data stopped runs once a minute and independent of the data stream.

The log snippet is no use in seeing what happened we would need to see the full file.

It appears you are using the WeatherLink Cloud station type? Do you have a Pro subscription?

[kj6rgx]

It appears you are using the WeatherLink Cloud station type? Do you have a Pro subscription?

Yes I do have a Pro subscription.

The log snippet is no use in seeing what happened we would need to see the full file.

Attached.

[mcrossley]

I take it your Cumulus MX is not receiving WLL broadcast data for some reason? The WLL station really works best if broadcasts are received.

That said, it really is data input stopped.

The data returned by the WLL for current conditions is the same (the data timestamp is the same) for the period I looked at when you were getting the messages.

The "current conditions" returned by the WLL are not really current. It is a copy of the last 1-minute update sent to the Davis weatherlink.com servers. If the connection to wl.com isn't working for some reason the WLL will buffer the updates until the link becomes available again. But in the meantime, it looks like it returns the same last successful update on the local API.

I think the coding of the current conditions local API is very poor - it should always return the latest values for all the sensors, not data that could be a minute out of date during normal running. And this case seems to show it could be much older. I'll have to try and test this theory with my WLL.

I have raised this with Davis and get it changed, but their response was the developer who wrote the WLL code has left the company - implying there will be no more updates! It's a shame as the original developer was responsive to queries and requests.

All that being said, if broadcasts were being received, they are really "live" data and would prevent the data input stopped messages.

[SamiS]

I take it your Cumulus MX is not receiving WLL broadcast data for some reason? The WLL station really works best if broadcasts are received.

A missing firewall rule maybe, if running on windows as kj6rgx’s forum profile suggests?

[kj6rgx]

I take it your Cumulus MX is not receiving WLL broadcast data for some reason?

I am not familiar with "WLL broadcast data". What I do know is my data is being sent to Weatherlink.com and is displayed correctly. However, my data at their site is not being "recorded" when I visit the data tab. I have been in communication with them about this, but so far no resolution.

In the mean time I have reconfigured CMX4 to use my Tempest station for data. If Weatherlink.com ever figures out why my data is not being recorded I may return my CMX4 setup to see if that was the cause of these errors. Appreciate you taking a look for me and attempting to solve.


Dan

[mcrossley]

When requested, the WLL continually broadcasts live data on your local network. This is how the WeatherLink app on your phone works. When connected to the internet it will update once a minute from weatherlink.com, but when your phone is connected to your local network the app display will change to showing "Live" against the wind speed title, and you will see it updating every 2.5 seconds.

This is how Cumulus should work, updating every 2.5 seconds from the WLL, yours is not, which implies the broadcast messages are being blocked on your computer. You may have to add a firewall rule to allow them in - an inbound rule allowing UDP port 22222 to reach Cumulus MX.

[PaulMy]

Hi,
@kj6rgx, Mark has indicated how the WLL should work and does for me with my station type Davis Weatherlink Live (type 11). However your earlier startup capture shows station type 19 Davis Cloud (WLL/WLC) and I am not sure if that makes a difference. If you have the Weatherlink Live device I'd try your settings as Station type Davis Weatherlink Live. This may not overcome your Weatherlink.com issue of not logging data but should give you live data while CMX is running.

Enjoy,
Paul

[kj6rgx]

I've given up on using Weatherlink anything...my Pro subscription is not working and I am trying to get a refund. I am now using the Tempest station for all data. The only errors I am seeing now look like this:

2024-08-09 08:55:53 - RealtimePHP[131]]: Timeout uploading to realtimegauges.txt
2024-08-09 08:55:53 - RealtimePHP[131]]: Timeout uploading to realtime.txt
2024-08-09 04:38:16 - PHP[Int]]: Timeout uploading to winddata.json
2024-08-09 04:38:15 - PHP[Int]]: Timeout uploading to soiltempdata.json
2024-08-09 04:37:44 - PHP[Int]]: Timeout uploading to pressdata.json
2024-08-09 04:37:43 - PHP[Int]]: Timeout uploading to extradewdata.json
2024-08-09 04:35:59 - PHP[Int]]: Timeout uploading to extradewdata.json
2024-08-09 04:35:59 - PHP[Int]]: Timeout uploading to extrahumdata.json
2024-08-09 04:35:21 - Realtime[127]: Warning, a previous cycle is still processing local files. Skipping this interval.
2024-08-09 04:35:04 - PHP[Int]]: Timeout uploading to pressdata.json
2024-08-09 04:35:04 - RealtimePHP[126]]: Timeout uploading to realtime.txt

Either my ISP or my internal LAN is probably the culprit of these errors...for now I am tired of troubleshooting.

Thanks all for the help.