March 1st update bug. **solved**

[_John C]

Just tried new March 4th update but still the same problem. Back to 5.0. It's great to be able to roll back . Would be sweet if we could roll back within V5.1.

[_John C]

Replying to "alexdelprete"

Ecowitt GW1000CA
WH65 Outdoor 7in1 2 arm array
WH45 Co2/PM2.5/PM10
WH41 PM2.5
WH57 Lightning Detector
WH31 Temp/Hum x8
WH55 Water Leak x4,

alexdelprete also has the same problem as myself but he has strangely vanished

[galfert]

I've emailed Boris. There is significant changes to firmware 1.6.6 that may cause some people to experience connectivity issues and not others. It likely is because everyone has different sensor combinations. Seems that the changes in firmware 1.6.6 are ignored in MB 5.0. That may make no sense but programs change. To me it just signifies that MB 5.0 parsed data differently.

[_John C]

Fingers crossed, we get an update

[alexdelprete]

Replying to "alexdelprete"

Ecowitt GW1000CA
WH65 Outdoor 7in1 2 arm array
WH45 Co2/PM2.5/PM10
WH41 PM2.5
WH57 Lightning Detector
WH31 Temp/Hum x8
WH55 Water Leak x4,

alexdelprete also has the same problem as myself but he has strangely vanished

I didn't vanish John. The global moderator galfert deleted my account.

Cool when a global moderator offends people, and doesn't accept unoffensive replies to his offensive posts. Nice way to manage the forums here.

I re-registered because I wanted to read what blatant excuses he's finding in order not to acknowledge there's a bug.

[alexdelprete]

I've emailed Boris. There is significant changes to firmware 1.6.6 that may cause some people to experience connectivity issues and not others. It likely is because everyone has different sensor combinations. Seems that the changes in firmware 1.6.6 are ignored in MB 5.0. That may make no sense but programs change. To me it just signifies that MB 5.0 parsed data differently.

It makes no sense, exactly as you said. Like I told you yesterday, something is changed in MB since 5.1.x in the way it parses data from the GW1000. GW1000 fw has NO MAJOR CHANGES, you keep telling this story, blaming ecowitt simply because you don't want to acknowledge there's a bug.

Regarding the deletion of my account, I was not surprised, you must be very nervous, it's bad when someone unveils your low level of knowledge and your arrogance, isn't it?

Anyway, if this is the way these forums are managed, by an incompetent and arrogant guy like you, bye bye Meteobridge: you've lost some license renewals and you'll get negative feedbacks about the solution if someone asks for advice, because support is managed by mediocre and arrogant people like you, who doesn't allow others to express different opinions.

[marioferrari22]

Here are my sensors:

Ecowitt GW1000
WH41 PM2.5
WH51
WH2320CE/wh4000

Bye

[marioferrari22]

Discussions and positions are useless,
the problem lies in the fact that if with the 5.0 release everything works both with the ecowitt 1.6.5 release and also with 1.6.6,
and while with the 5.1 release of March 1st and later it does not work,
the problem lies there, just look at the way the data is managed and the solution is found, there is no other way.
Without blaming anyone, but trying to solve the problem

[admin]

If someone is giving me access to a problematic GW1000 setup I will make some tests and try to fix it.

I know that from a user perspective you just want things running. But to be honest this GW1000 frequent and bloody updates, very poorly designed and even worse documented are hard to follow and are a pain in the ***. I know that their stuff is popular because being cheap and allowing tons of sensors to be connected. Unfortunately, this cheapness comes with the price of an unstable API, lack of IT architecture design and inability to provide a reasonable documentation. in short, it is a mess.

When you are a fan of this GW1000 hardware, be prepared to suffer again and again unless you freeze the version of your GW1000. Next update will again kill things for sure.

[_John C]

Pm'd you my remote access details. Thanks for your help

[marioferrari22]

If you can solve the problem of the block, who makes me stare at the 5.0 release relative to the GW1000,
I will certainly not upgrade to any release after the current one (1.6.6).
Thanks in advance to the staff
Thank you

[admin]

I think I fixed it. Please try just released update. Let's see when next API change makes rework necessary again...
My thanks go to user "_John C" for providing me remote access which did speed up things a lot.

[_John C]

Thank you so much
Meteobridge 5.1 (Mar 10 2021, build 3804) working.

[galfert]

Thank you Boris for tackling these API changes. I, having read the lastest API documentation as difficult as it is to read, it was a big change with this lastest update as it went beyond just adding a new sensor. Hopefully FO / Ecowitt will soon finalize these API changes and publish some better documentation. In all fairness to FO / Ecowitt this is one of the reasons that the API is not openly available and is only provided to key developers that are willing to roll with the changes. This situation currently allows FO / Ecowitt to keep making drastic changes to the API without needing to worry too much about backwards compatibility.

I recommend that users do not jump on new Ecowitt firmware unless they want to be the guinea pig. Some users have extra GW1000 for the very purpose of having a test system and a production system. That might be something to consider and it is totally feasible given the low price point of having an extra GW1000. It might not be a bad idea to just have a complete GW1001 as backup for any sensor that may go out, that gives you time to the replace your much nicer WS80, WS68, WH32, and WH40...meaning don't have the WH65 (all-in-one) already mounted ...but just kept inside on standby (batteries removed). Remember the WH65 sensor are superseded by any active WS80, WS68, WH32, and WH40...which means that if only your WH32 temperature/humidity sensor goes out, you can run the WH65 all-in-one with the remaining separate components and they will take precedence, leaving you to automatically only use the WH65 for temperature/humidity until you get around to replacing the defective WH32.

[alexdelprete]

I think I fixed it. Please try just released update. Let's see when next API change makes rework necessary again...
My thanks go to user "_John C" for providing me remote access which did speed up things a lot.

Thanks a lot for the fix Boris. May I ask what API changes exactly broke things up? I have other apps who leverage the API that continued to work with 1.6.5 and 1.6.6 without issues, and they use UDP too.

Also, why did MB 5.0 continue to work perfectly with these API changes?

Thanks again for your work and support.