Ecowitt GW1000 and Meteobridge

[gand]

Hi
It seems that after upgrading to GW1000 firmware 1.5.9, I have random gaps, All gaps are 15 minutes long and I can have up 10 gaps a day.

I'm running:
Meteobridge 4.3 (May 29 2020, build 3071), FW 1.3

Any ideas?

Gert

[galfert]

This issue is also being discussed in the MB Pro section, although it obviously is affecting both Pro and Standard.
Link to discussion on MB Pro section:
viewtopic.php?f=61&t=14887

[ConligWX]

Hello.

Is there a changelog for the new ecowitt firmware?

obviously after upgrading something has changed, without "what has changed" in the firmware, your asking a question that has no definitive answer. MB has not changed at all.

Perhaps MB needs an update, but without ecowitt's changelog, how could one fix the issue?

[galfert]

Yes there is an official changelog though it is not an end user changelog. It is called the GW1000 API documentation. And yes the API has changed significantly enough to have caused the issue I believe. Boris has it...because I sent it to him. There was also an end user changelog you could say in the WS Veiw app notification pop-up that mentioned that firmware version 1.5.9 would add support for new sensors (that aren't for sale yet). These sensors were incorrectly called WN34 instead of WH34 in this notification pop-up.

GW1000 1.5.9 firmware.jpg (25.15 KiB) Viewed 5457 times

[gand]

Hi

Upload to ecowitt.net from GW1000 works fine and no gaps.

Uploading to Weewx/interceptor from the GW1000 works fine too, again no gaps here.
Uploading from GW1000 to MB still gives 15-minute gaps. When they come is random

Gert

[galfert]

Hi

Upload to ecowitt.net from GW1000 works fine and no gaps.

Uploading to Weewx/interceptor from the GW1000 works fine too, again no gaps here.
Uploading from GW1000 to MB still gives 15-minute gaps. When they come is random

Gert

Yes, true. Which means that the GW1000 is not restarting nor resetting nor freezing up. Also any other GW1000 built in upload services continue without stopping (WU, WeatherCloud, Ecowitt.net, WOW). The problem is with the GW1000 API method of data extraction. But there are are other software that also use this API method to get data from the GW1000 and they aren't reporting issues (Cumulus MX, Weather-Display). Hence it seems it is just a compatibility issue in how the MB processes and parses the incoming API data format which has changed in version 1.5.9 of the GW1000 firmware. Only Boris can let us know for sure and if he can do anything about it or if he feels that there is a bug in the GW1000 API. Let's give him some time to work this out.

[gand]

Hi

I've decided to move away from Meteobridge. In my case, it doesn't work and not a single comment from Boris. I do not expect a solution here and now, but did expect a comment from him, about a future solution. Or at least an explanation of what the error may be. Maybe it's not Meteobridge, but Ecowitt, who has the fault.

Meteobridge should support the GW1000, but it does not.

Too bad, I've used Meteobrige for many years and have several of them.

Gert

[Mattk]

Hi

I've decided to move away from Meteobridge. In my case, it doesn't work and not a single comment from Boris. I do not expect a solution here and now, but did expect a comment from him, about a future solution. Or at least an explanation of what the error may be. Maybe it's not Meteobridge, but Ecowitt, who has the fault.

Meteobridge should support the GW1000, but it does not.

Too bad, I've used Meteobrige for many years and have several of them.

Gert

Maybe you should have a whinge to Ecowitt, or don't you even have a door to bang on there. You don't appear to have much patience at this time, yet expecting everybody else to jump

[danoh]

Same issue here.

GW1000 v 1.5.9
MB 4.3 (Jun 8 2020, build 3100), FW 1.3

MB just stops receiving data from the GW1000 randomly it seems. Sometimes I have to fix it twice an hour, sometimes it will work for 3 or 4 hours straight without intervention.

Mine fixes itself, because I used to have an ObserverIP that always needed fixing and I left that logic in place for the GW1000. But getting alerts about it is very annoying.

If it helps any for Boris, you can "fix" it when it happens by restarting the logger process on the MB. (/usr/bin/rcloggerd restart)

Capture1.PNG (25.13 KiB) Viewed 5336 times

Capture2.PNG (79.52 KiB) Viewed 5336 times

[kd7eir]

Maybe you should have a whinge to Ecowitt, or don't you even have a door to bang on there. You don't appear to have much patience at this time, yet expecting everybody else to jump

Perhaps you missed the part about how EVERY OTHER SERVICE related to the GW1000 does NOT have this issue. That means the issue lies squarely at the feet of Meteobridge.

[kd7eir]

Hi

I've decided to move away from Meteobridge. In my case, it doesn't work and not a single comment from Boris. I do not expect a solution here and now, but did expect a comment from him, about a future solution. Or at least an explanation of what the error may be. Maybe it's not Meteobridge, but Ecowitt, who has the fault.

Meteobridge should support the GW1000, but it does not.

Too bad, I've used Meteobrige for many years and have several of them.

Gert

Same deal with Meteobridge and the lightning detector. They have known about this issue since April 29, roughly 40 DAYS and yet they have done NOTHING to resolve the issue. It's been 38 DAYS since they even addressed the issue, and all that inspiring communication said was "A remote login would be fine."

Face it folks, Meteobridge is fast becoming just another pile of abandonware. Meteobridge would like to thank all of the people that PAID THEM in exchange for nonexistent support.

[Mattk]

Maybe you should have a whinge to Ecowitt, or don't you even have a door to bang on there. You don't appear to have much patience at this time, yet expecting everybody else to jump

Perhaps you missed the part about how EVERY OTHER SERVICE related to the GW1000 does NOT have this issue. That means the issue lies squarely at the feet of Meteobridge.

"EVERY OTHER SERVICE"

Can you list "every other service" as it might help identify what the "other services" are?

[ConligWX]

Perhaps you missed the part about how EVERY OTHER SERVICE related to the GW1000 does NOT have this issue. That means the issue lies squarely at the feet of Meteobridge.

What is this "Every other service" do you mean the services running on the running on the GW1000?

Looking at the data provided by the original post, they clearly stated after a firmware upgrade of the GW1000, problems stated to happen.

The issue is Ecowitt software developers have secretly changed their protocol and/or timings without notifying anyone. How on earth is that the fault of Meteobridge?

MB will need some workaround yes, but pointing fingers at MB and then SHOUTING ITS MB's FAULT makes your comments laughable.

If perhaps everyone affected creates a structured report of your findings so that Boris can understand what Meteobridge devices are affected and then he can diagnose and possibly rectify the issue you you guys.

[galfert]

Perhaps you missed the part about how EVERY OTHER SERVICE related to the GW1000 does NOT have this issue. That means the issue lies squarely at the feet of Meteobridge.

What is this "Every other service" do you mean the services running on the running on the GW1000?

Did you read my previous post in this thread? I clearly mentioned how Cumulus MX and Weather-Display do not have any problems with GW1000 firmware 1.5.9.

Looking at the data provided by the original post, they clearly stated after a firmware upgrade of the GW1000, problems stated to happen.

If you understand how the API works it gives you insight into how the data is sent from the GW1000. It is a string of hexadecimal code that refers to sensor ID (in hex) followed by sensor data value (in hex). In firmware 1.5.9 the length of the returned API data payload has changed because there is some extra information being sent by the GW1000 (extra features and supporting new sensors). Any application built to read this data payload needs to be written to first store this data stream temporarily in a data processing loop, then the application must parse (read, search and pull out and store values) for each sensor before looping and repeating the process. It is very likely that the parsing is stumbling with the data payload because it is different than expected as it has changed in GW1000 firmware 1.5.9. The firmware had to change to both add features and support new sensors (soil temperature) that aren't for sale yet but are in development and testing. Software like Meteobridge need to keep up with these changes.

It is possible to write parsing routines that aren't affected by data payload changes if they search for data rather than expect a given sensor to be in a given position in the hex data packet. This is up to the software developer in their programming style how it decides to deal with the data. It is no reflection on the quality of the software developer. Sometimes changes affect your work and other times not. It could just as easily been an issue for Cumulus MX and Weather-Display. There are many tradeoffs to programming decisions; Speed, RAM efficiency, and code reliability, and overall complexity that affects code maintenance. So you can't criticize developer's decisions without actually seeing the source code.

The issue is Ecowitt software developers have secretly changed their protocol and/or timings without notifying anyone. How on earth is that the fault of Meteobridge?

This is not true. Ecowitt have not done these changes in secret. Ecowitt publishes API documentation for the GW1000 that clearly describes and defines the API for software developers to follow. This documentation has been made available to Boris since it first started supporting the GW1000. I should know, because my GW1000 was the first to ever use the Meteobridge. I worked with Ecowitt and Boris to supply this API documentation and test. I have supplied several API documentation revisions since and the Meteobridge has been updated to support previous changes. Boris has the latest 1.5.9 revision. Don't ask me for the API documentation. It is only provided to major software developers like Cumulus MX, Meteobridge, Weather-Display. It has been a staged rollout to the various developers. I'm currently working with WeeWX as they are next. Ecowitt is the one controlling this not me. I'm under NDA.

MB will need some workaround yes, but pointing fingers at MB and then SHOUTING ITS MB's FAULT makes your comments laughable.

Nobody should be shouting. Things happen. Changes need time sometimes. We don't know what Boris is dealing with (personal or otherwise). I can see that he hasn't logged into the forum since Sunday (4 days ago). I don't know if that is normal. Regardless he should be able to step back and have a week off if he needs it. We should all be more patient.

If perhaps everyone affected creates a structured report of your findings so that Boris can understand what Meteobridge devices are affected and then he can diagnose and possibly rectify the issue you you guys.

Boris has all that he needs. I sent him a GW1000 way back when. He has the latest GW1000 API documentation. He can remote into other people's Meteobridge with different sensors. He just needs time.

[ConligWX]

Well I must stand corrected then, however you should have replied to the concerned individual in this thread rather than just me after all I dont have an issue with Meteobridge or its support.