CMX reading on start up but station not updating [SOLVED]

[Cambium]

Could you create a CMX logfile with debug and data logging on please.
(try to keep the catch up as short as possible as the issue apparently is not in that phase)

Not sure I understand that. Attached the Diags and ServiceLog file

ServiceConsoleLog.txt

20230623-070938.txt

Now its not reading at all. Stuck on 12am for station update.

[HansR]

Use Settings=>Program Settings=>Logging Options and make sure Debug Logging and Data Logging are ticked (I have an idea they are not). Let it run for some 10 minutes and post the log. (You can than switch the Debug and Data logging off again).

[Cambium]

Use Settings=>Program Settings=>Logging Options and make sure Debug Logging and Data Logging are ticked (I have an idea they are not). Let it run for some 10 minutes and post the log. (You can than switch the Debug and Data logging off again).

They have been ticked since starting this thread. Attached the logs again since its been running over 10 minutes. Thanks!

20230623-070938.txt

[HansR]

OK. So now we wait for Mark

[philpugh]

Some thoughts...

Has your Windows system changed it's IP address? I.e. does it have a permanent (non DHCP) address? Is this the same address as set up on the console of your weather station in the Custom Settings?

Is your station reporting data to Ecowitt.net correctly ? Can you see this data on ECOWITT.NET? And does it agree (loosely) with the TP3000 console display?

The reason I ask is that for the 45+ mins of this log the max gust = 0 each time - also the inital data fetch from ecowitt.net is only returning unit settings and not any data values.

[philpugh]

Just a bit more. I have three ecowitt stations running (all using the API interface not HTTP) but I do have an ECOWITT console which I just set up to do HTTP protocol and with all logging enabled I get this attached log file - ignore the rain error - I suspect it's due to an old station having been tested with this setup in the past!

Things to note -

There is a clear set of data readings being logged - not present in your log file - check the logging options and if in doubt set them all!

I haven't set this station up to report to ecowitt.net - so the data fetch at the start "fails".

Hope this helps a bit

[Cambium]

Has your Windows system changed it's IP address? I.e. does it have a permanent (non DHCP) address? Is this the same address as set up on the console of your weather station in the Custom Settings?

I was told not to have a permanent IP due to security reasons but its not a big deal to look at the new IP when CMX starts and to change it in the WS View app through configuration. Been doing that for years and was fine.

Is your station reporting data to Ecowitt.net correctly ? Can you see this data on ECOWITT.NET? And does it agree (loosely) with the TP3000 console display?

Yes it does. Ecowitt.net showing data every 5 minutes while my settings on console and CMX are on 1 minute. I prefer CMX reading every 1 minute when running due to missing wind gusts. On catch up I dont mind if it only gets every 5 minutes.


pugh post_id=172925 time=1687794972 user_id=5473]
There is a clear set of data readings being logged - not present in your log file - check the logging options and if in doubt set them all!
[/quote]

Thanks for your thoughts and efforts! The data is being read, just not updating when running

Whats most interesting is my log reading with the ffff in front of the IP. ODD. And why is it 1.9??? Nothing in the configuration has 1.9.

2023-06-17 16:58:09.810 WS Client Disconnected: ::ffff:192.168.1.9,

And just a reminder, CMX is reading the data only when its first started, everything is there, it just doesnt update as its running.

New Diags

20230627-131757.txt

[SamiS]

Whats most interesting is my log reading with the ffff in front of the IP. ODD. And why is it 1.9??? Nothing in the configuration has 1.9.

2023-06-17 16:58:09.810 WS Client Disconnected: ::ffff:192.168.1.9,

As I said before, the ffff is related to IPv6. For some reason your network / computer / weather console uses one of the IPv4->IPv6 transition mechanisms that I personally have never seen earlier in real life. It might be part of your problem or might not be.

https://en.wikipedia.org/wiki/IPv6#IPv4 ... _addresses

[Cambium]

Whats most interesting is my log reading with the ffff in front of the IP. ODD. And why is it 1.9??? Nothing in the configuration has 1.9.

2023-06-17 16:58:09.810 WS Client Disconnected: ::ffff:192.168.1.9,

As I said before, the ffff is related to IPv6. For some reason your network / computer / weather console uses one of the IPv4->IPv6 transition mechanisms that I personally have never seen earlier in real life. It might be part of your problem or might not be.

https://en.wikipedia.org/wiki/IPv6#IPv4 ... _addresses

I tried unchecking one or the other and same issue. Not that but thank you for the idea.

[SamiS]

Windows actually does not disable ipv6 support even if you uncheck the protocol. It must be done via regedit and after adding the proper key rebooting the computer. But since the logs indicate that the ipv6 address is used by the weather station (client), not the computer itself, I don’t think disabling it from the computer would help.

I would try to disable ipv6 from the weather station itself. If it does not offer this option in ws view, then I would check the console network setup menu itself.

[Cambium]

Windows actually does not disable ipv6 support even if you uncheck the protocol. It must be done via regedit and after adding the proper key rebooting the computer. But since the logs indicate that the ipv6 address is used by the weather station (client), not the computer itself, I don’t think disabling it from the computer would help.

I would try to disable ipv6 from the weather station itself. If it does not offer this option in ws view, then I would check the console network setup menu itself.

Interesting but again, it was working before the windows restart, nothing was changed on the station itself and there's no option to disable it with the station itself. Also, CMX IS reading the data, if the IP was an issue wouldnt it not read any data? It is reading and recording, its just not updating while running

[SamiS]

A picture is worth more than 1000 words, I hope.

Your station and CMX do not currently communicate successfully at all. The data you are seeing on startup, comes from historical catch-up from ecowitt.net. When using HTTP Ecowitt station type, CMX is just a passive server waiting for data, that the weather console should send, if the custom upload server is correctly configured and network between them works and firewalls allow required traffic. In your case this connection does not work for some reason.

Sorry for the messy picture, but it was drawn by pen on my mobile phone.

[Cambium]

A picture is worth more than 1000 words, I hope.

Your station and CMX do not currently communicate successfully at all. The data you are seeing on startup, comes from historical catch-up from ecowitt.net. When using HTTP Ecowitt station type, CMX is just a passive server waiting for data, that the weather console should send, if the custom upload server is correctly configured and network between them works and firewalls allow required traffic. In your case this connection does not work for some reason.

Actually very helpful. Thank You.

So I had chosen HTTP Ecowitt this whole time. Now I'm trying others. I have to look back at previous threads to see which it was. Thinking maybe station type is the issue?? Then again, would it even "catch up" if this setting was wrong?



EDIT...... NOPE ITS NOT THAT. I had the setting right. Ugh

viewtopic.php?t=19886

[Cambium]

Something I just noticed. When running CMX and it "catches up" the time is a future time.

Current time I started running the program was 1:03pm but its showing it was processing files to 1:08pm. Could this be part of the issue its not reading my station when running?? PC clock matches CMX last update. My station matches them too.

[SamiS]

Unfortunately that ”5min to future oddity” is a feature (or a bug) in ecowitt.net api, it does not cause any issues on CMX running.

Edit. I see it too in both of my own (working) Cumulus instances that have Ecowitt stations, so first hand experience.