Topic: WS80/GW1100 issue

[HansR]

Please note my description on the CumulusMX forum.

[EDIT: as you apparently can't see the images if you don't have a Cumulus forum account I replicate the post here fully]

I have an installation as depicted in my hand made drawing (see scan attached, note that the upper website nr 2 must be website nr 1). The issue is that at 9h31 today the wind and T/H sensor of the WS80 (which I use as main T/H sensor as well) went haywire on one of my GW1100. This is shown in the two images of Ecowitt.net attached as well. Important to realise that both GW1100's are attached to the same WS80 device.

My conclusion is that it is the GW1100 firmware reading the WS80 which has a bug somewhere, probably in the difference between the WS80 and WS90 (what kind of sensor is this??? it is not on the Ecowitt.comm shop site). Both GW1100's have the same firmware : GW1100A_V2.0.9 which is automatically installed (I don't know when, the installation itself might be the issue).

Anyway, when I concluded the GW1100 was the problem, I rebooted and the problem went away.
I sent a link of this message to Ecowitt Support and posted it on WXforum.net.

 [ You are not allowed to view attachments ]
My configuration

[ You are not allowed to view attachments ]
Erroneous GW1100 data (first GW1100)

[ You are not allowed to view attachments ]
Correct GW1100 data (second GW1100)

[Gyvate]

@Hans: your pictures can only be seen if someone is a Cumulus forum member !
Looks like your GW1100 reports fake/not existing battery values for a non-exisitng WS90 to ecowitt.net.
This looks like an error in either the console or WiFi firmware component.
I have a similar configuration, but it's not shown on my console page on ecowitt.net.
I'm on firmware 2.0.8. What's your release ?

[broadstairs]

He said V2.0.9 on the Cumulus forum. I can confirm my GW1100 does not show the WS90 battery and it's on V2.0.9 as well. Attached are the images from that forum.

Stuart

[Gyvate]

OK - only looked at the pictures ...
I have suggested a reboot/power cycle of the one which has shown non-plausible values.
If it doesn't help, doing a factory reset.
And take it from there.
There maybe some EMR issue, depending on where the GW1100 are located and how their power supply is implemented (direct plug-in, extension cable, quality of extension cable ...)

[HansR]

I think my description is clear already that after my reboot the problem was solved so afaiac it is a firmware problem which apparently does not catch and correct transmission errors. Note that the issue of the WS90 may be a side effect. I don't have a WS90 so it may not come up at all. My direct issue is the invalid values of Wind, Temp and Hum. It's a total fail of the GW1100 wrt the WS80.

Up to Ecowitt to find out and to correct.

I just report the error here so others may know what to do. I am not expecting a solution from you guys

[HansR]

There maybe some EMR issue, depending on where the GW1100 are located and how their power supply is implemented (direct plug-in, extension cable, quality of extension cable ...)

The WS80 is 40 meter away from the GW1100 and running on batteries, no cables at all.

[Rover1822]

Is there any possibility that someone else has a similar system nearby?

[Gyvate]

There maybe some EMR issue, depending on where the GW1100 are located and how their power supply is implemented (direct plug-in, extension cable, quality of extension cable ...)

The WS80 is 40 meter away from the GW1100 and running on batteries, no cables at all.

Again, the question with the position and the cable was with the console not with the sensor.
The GW1x00 are known for issues with power supply and closeness to other electronic devices.

[HansR]

Is there any possibility that someone else has a similar system nearby?

No, not within 100m

[HansR]

Again, the question with the position and the cable was with the console not with the sensor.
The GW1x00 are known for issues with power supply and closeness to other electronic devices.

The GW1100 is connected to a power supply - a Samsung phone power supply - directly to an outlet, no cables.

It has run for more than a month - since the last reboot with firmware GW1100A_V2.0.7 btw -  without a problem and there are several other similar devices (RPi's, ESP32's) in proximity and on the same branch of power lines in the house. None has a problem whatsoever.

And beyond that: I expect from firmware of a 24/7 device (I look at the GW1100 that way) that it is able to counter minor power disturbances and if a real problem occurs it should reboot (like it would if a real power failure and power restore would occur). It is not good enough to conclude cables or power supply may be the cause of malfunction.

A device like this should not malfunction. When it detects a serious error it should notify Ecowitt and reboot. That in itself is not all that difficult.
So for me, the problem is with Ecowitt now and I think they understand the problem.

Best wishes btw 

[DelChard]

I think my description is clear already that after my reboot the problem was solved so afaiac it is a firmware problem which apparently does not catch and correct transmission errors. Note that the issue of the WS90 may be a side effect. I don't have a WS90 so it may not come up at all. My direct issue is the invalid values of Wind, Temp and Hum. It's a total fail of the GW1100 wrt the WS80.

Up to Ecowitt to find out and to correct.

I just report the error here so others may know what to do. I am not expecting a solution from you guys

I also have 2 GW1100 gateways, and have experienced the same problems. Both gateways run V2.0.9 firmware.
The good GW1100 is located upstairs adjacent my router, NAS and printer. The errant GW1100 is located in my conservatory and has just one glass panel between it and the WS80
I also believed that rebooting the errant gateway had fixed the issue. However this is not the case, I still get spurious temperature readings.
I also followed Gyvate's advice and tried repositioning the gateway using the full length of the supplied USB cable.
As a last resort. I have now swapped the positions of the 2 gateways to see if the error is with the individual gateway or the location.
As can be seen from the attached, I might have to waiit a few days.

Initially, I also had a spurious battery for WH45 which I don't have.
I don't believe this will disappear from ecowitt.net, so I deleted the device and re added it. [ You are not allowed to view attachments ]

[Gyvate]

Again, the question with the position and the cable was with the console not with the sensor.
The GW1x00 are known for issues with power supply and closeness to other electronic devices.

The GW1100 is connected to a power supply - a Samsung phone power supply - directly to an outlet, no cables.

It has run for more than a month - since the last reboot with firmware GW1100A_V2.0.7 btw -  without a problem and there are several other similar devices (RPi's, ESP32's) in proximity and on the same branch of power lines in the house. None has a problem whatsoever.

And beyond that: I expect from firmware of a 24/7 device (I look at the GW1100 that way) that it is able to counter minor power disturbances and if a real problem occurs it should reboot (like it would if a real power failure and power restore would occur). It is not good enough to conclude cables or power supply may be the cause of malfunction.

A device like this should not malfunction. When it detects a serious error it should notify Ecowitt and reboot. That in itself is not all that difficult.
So for me, the problem is with Ecowitt now and I think they understand the problem.

Best wishes btw 

Whatever your opinions and demands towards Ecowitt
facts are:
- that all these devices you name produce electromagnetic fields
- a power supply also does this (transformer)
- the GW1100 is delivered with an USB extension for good reason
- the GW1x00 are known for showing (temporary) malfunctioning when positioned too close to certain EMF producing devices
- it's not the GW1x00 task to provide a stable power supply, that's what proper transformer devices or UPSs do
- no firmware update is going to change your EM "climate", only you can do this by proper positioning or shielding of your devices

that doesn't mean that software bugs in the existing firmware are not to be corrected - this should of course be done if a bug has been identified, but we have to eliminate potential hardware issues before blaming the software

Not to be excluded that you have both a hardware and software issue.

A Happy and Healthy New Year too 

[HansR]

As a last resort. I have now swapped the positions of the 2 gateways to see if the error is with the individual gateway or the location.
As can be seen from the attached, I might have to waiit a few days.

Initially, I also had a spurious battery for WH45 which I don't have.
I don't believe this will disappear from ecowitt.net, so I deleted the device and re added it. [ You are not allowed to view attachments ]

The swap is an interesting exercise. Keep us posted!

And those battery entries for non-existent devices must be an anchor for Ecowitt in locating the problem (bug: because I am convinced it simply is a bug).

[davidefa]

@DelChard
Are both gw1100 receiving the same ws80 sensor?
Or is one gw1100 receiving the ws80 sensor ( the one that show the intermittent failure ) and one gw1100 is receiving another sensor ( a ws80 or a different one )?

[mcrossley]

Happy New Year!

I am not familiar with the Ecowitt radio protocol, but I would have thought that they implemented a checksum mechanism on the data packets that would all but eliminate spurious data being generated from interference?

The chances of random interference generating a valid packet and checksum for a non-existent device must be vanishingly small?

[DelChard]

@DelChard
Are both gw1100 receiving the same ws80 sensor?
Or is one gw1100 receiving the ws80 sensor ( the one that show the intermittent failure ) and one gw1100 is receiving another sensor ( a ws80 or a different one )?

For clarity I will refer to Gateway and Gateway 2 (this is how they are named on ecowitt, although Gateway 2 is private).
The set up was:-
Gateway receives its outdoor T & H from a WH32EP (with the sensor located in the shade) , So far this Gateway has never shown spurious readings, despite ( in my book ) being closer to EMR sources (Synology NAS, Asus Router, Cyberpower UPS, all within 1m)
The UPS supplies a surge protected multiway socket supplying all the devices. The Gateway receives its power via the supplied cable from a USB port on the Asus router.
Gateway 2 receives its outdoor T & H from the WS80 ( for no other reason than curiosty).
Gateway 2 located in conservatory, Powered from a mutiway socket (not surge protected).
Potential EMR sources (WH41 located in the conservatory 1m away). (TV, Soundbar, Humax box, Ruark music streamer/DAB radio, Cordless phone, Located in lounge 3m away through cavity wall).

As per previous post, the locations of Gateway and Gateway 2 have now been transposed. I have left the sensor configurations alone.

I have now made Gateway 2 public (https://www.ecowitt.net/home/index?id=69557)
Gateway (https://www.ecowitt.net/home/index?id=68583)
And all sensor descriptions include all info.

Gateway was purchased on Amazon, seller ecowitt.eu on 8th Dec
Gateway 2 was purchased from Weather Spares as part of GW1103 bundle on 20th Dec

I suspect they are different manufacturing batches

I'm attaching a messy chart from Gateway 2 showing the very worst error (the data is no longer available, as I deleted and re-added the device)

I'll post back in about a week, wilth how the results of the transposition work out.
Hope this might prove useful to others.

All units are 868MHz
Just in case anyone notices the wind speed differences (I've been playing with wind shear formulas, Gateway 2 has a gain factor applied)

 [ You are not allowed to view attachments ]

[davidefa]

@DelChard
Thanks for the clarification.
This ws80 erroneous reading is a known problem of this sensor.
On the ecowitt site there are 2 software updates for the ws80 ( first addressing erroneous wind reading when raining, this should not be your case, the seconds addressing 'a bus conflict' when reading T/H sensor, this could be your case ).
As you already swapped the gw1100 I suggest you to wait before doing the software update ( in the case you want to do the software update ). until it repeats the error ( showing that the problem is not in the gw1100 )

P.S.
On the contrary the 'ghost wh45' you recorded should be related to problem HansR initially posted

[DelChard]

@DelChard
Thanks for the clarification.
This ws80 erroneous reading is a known problem of this sensor.
On the ecowitt site there are 2 software updates for the ws80 ( first addressing erroneous wind reading when raining, this should not be your case, the seconds addressing 'a bus conflict' when reading T/H sensor, this could be your case ).
As you already swapped the gw1100 I suggest you to wait before doing the software update ( in the case you want to do the software update ). until it repeats the error ( showing that the problem is not in the gw1100 )

P.S.
On the contrary the 'ghost wh45' you recorded should be related to problem HansR initially posted

Thank you
I'm aware of the firmware from https://www.wxforum.net/index.php?topic=42662.0
I originally thought this was my issue, and posted accordingly.
Gyvate made me aware of the GW1100 possibility.
The only other WS80 issue I had, was due to forgetting the soft reset after installing the batteries.
I've downloaded the update V1.2.0 installed Dfuse and relevant USB driver, should it prove necessary.
I suspect a hardware variation between the 2 gateways, But I'm keeping an open mind.

[davidefa]

In my opinion the problem (HansR and others reported ) lays in the 'sensor autoassociation':
- every new sensor you add is 'autorecognized' and added to the sensor list*
Easy fix/solution would be to add an option to enable(default)/disable this 'sensor autoassociation' ( super easy to do )

The rationale is: 99.99999% of the time I'm not adding a new sensor why this thing should pass 100% of his time searching for a new sensor?
The answer is to help the 'basic user'.
This fix should be good for basic and advanced users ( in italian I'd say 'salvare capra e cavoli' )

NOTE *
If this is a wh31 ch8 this could end up unnoticed
If this is a wh90 ( that replaces your outdoor sensor ) this could pass less than unnoticed

[DelChard]

In my opinion the problem (HansR and others reported ) lays in the 'sensor autoassociation':
- every new sensor you add is 'autorecognized' and added to the sensor list*
Easy fix/solution would be to add an option to enable(default)/disable this 'sensor autoassociation' ( super easy to do )

The rationale is: 99.99999% of the time I'm not adding a new sensor why this thing should pass 100% of his time searching for a new sensor?
The answer is to help the 'basic user'.
This fix should be good for basic and advanced users ( in italian I'd say 'salvare capra e cavoli' )

NOTE *
If this is a wh31 ch8 this could end up unnoticed
If this is a wh90 ( that replaces your outdoor sensor ) this could pass less than unnoticed

Thankfully your English is better than my Italian.
I have no intention of making any changes unless I see any further error condition.
Gateway 2 did have a full reset initially (battery removed from WH32EP to prevent recognition).
And no sensors added since.
I intend to purchase some additional sensors, but will not make live until a conclusion is reached.

[broadstairs]

In my opinion the problem (HansR and others reported ) lays in the 'sensor autoassociation':
- every new sensor you add is 'autorecognized' and added to the sensor list*
Easy fix/solution would be to add an option to enable(default)/disable this 'sensor autoassociation' ( super easy to do )

The rationale is: 99.99999% of the time I'm not adding a new sensor why this thing should pass 100% of his time searching for a new sensor?
The answer is to help the 'basic user'.
This fix should be good for basic and advanced users ( in italian I'd say 'salvare capra e cavoli' )

NOTE *
If this is a wh31 ch8 this could end up unnoticed
If this is a wh90 ( that replaces your outdoor sensor ) this could pass less than unnoticed

I agree with this - on my GW1000 I went through and disabled everything I do not have so this auto discovery is not performed at all but that is a very tedious task and I have not (yet) done it on my GW1100 which is still not live.

By the way my GW1100 shows two sensors in the battery information I do not have and neither follow the Ecowitt protocol to indicate they are offline! They do not show up as sensor readings in any way just battery info.

Stuart

[whitecitadel]

Interesting thread, not sure I can add much help other than has anyone tried putting clip on ferrites on the WS1100 usb cable if it’s susceptible to RFI?

Mine is on the back of my desk at the moment where I stuck it some months ago for testing and on an Anker usb charger that is always charging something else I find, kids iThings, bike lights, cycling gps, batteries etc and I have had no issues, my study is not particularly quiet electrically with several PC’s that can be on or off, network gear and a 3D printer which I am sure doesn’t have the best quality psu fitted.

DelChard you sound like your in the UK so apart from the obvious differences between the ASUS supply and the wall brick in the conservatory there could be a difference on the noise on the mains ring. Assuming you have the usual UK ring upstairs and downstairs there could be something on the same ring as the conservatory that is electrically noisy. The cyber power UPS will have a LC filter in it for sure that is cleaning up the supply before the router.

Things like dishwashers and washing machines should have suppressors in them but watch out for any pattern like bad data starts after a certain appliance is used etc.

I had forgotten about the WS80 firmware, I had it on my desk yesterday and could easily have updated it but now it’s up a pole on the side of the garage, no bad data yet but I assumed it had latest FW and as per other thread no way to tell until it’s usb connected.

Neighbours already complaining about the new pole! I used some T&K brackets and a sturdy pole and it’s certainly over engineered now it’s up so I might yet take it down to fit a smaller pole and bracket so will have to remember the firmware if I do.

HansR - I am behind your theory your gateway may have some small difference, it could still be interference though and one is able to reject it better. At the moment products seem to be made with the materials that can be obtained rather than the original design, I would not be surprised if some IC or components are different between batches on these things, I only setup my 2551 display this week (under the tree for Xmas) but it seems to be ESP based looking at its WiFi name, these things must be built in batches and I am sure with global supply some differences occur.

[Gyvate]

In my opinion the problem (HansR and others reported ) lays in the 'sensor autoassociation':
- every new sensor you add is 'autorecognized' and added to the sensor list*
Easy fix/solution would be to add an option to enable(default)/disable this 'sensor autoassociation' ( super easy to do )

The rationale is: 99.99999% of the time I'm not adding a new sensor why this thing should pass 100% of his time searching for a new sensor?
The answer is to help the 'basic user'.
This fix should be good for basic and advanced users ( in italian I'd say 'salvare capra e cavoli' )

NOTE *
If this is a wh31 ch8 this could end up unnoticed
If this is a wh90 ( that replaces your outdoor sensor ) this could pass less than unnoticed

I agree with this - on my GW1000 I went through and disabled everything I do not have so this auto discovery is not performed at all but that is a very tedious task and I have not (yet) done it on my GW1100 which is still not live.

By the way my GW1100 shows two sensors in the battery information I do not have and neither follow the Ecowitt protocol to indicate they are offline! They do not show up as sensor readings in any way just battery info.

Stuart

@Stuart
what sensors would that be ? Can you provide those sensor names ?
In the firmware they (Ecowitt) sometimes still use the old predecessor sensor names ...

[broadstairs]

@Stuart
what sensors would that be ? Can you provide those sensor names ?
In the firmware they (Ecowitt) sometimes still use the old predecessor sensor names ...

Yes

Code: [Select]

Sensor WH65 Sensor ID 0000006d Battery Status 255 Signal Status 00
Sensor WH34 CH1 Sensor ID 00b54a22 Battery Status 255 Signal Status 00

protocol definition is for ID to be x'FFFFFFFF' if offline. WH34 CH2 through CH8 show offline.

Stuart

[broadstairs]

@Stuart
what sensors would that be ? Can you provide those sensor names ?
In the firmware they (Ecowitt) sometimes still use the old predecessor sensor names ...

Yes

Code: [Select]

Sensor WH65 Sensor ID 0000006d Battery Status 255 Signal Status 00
Sensor WH34 CH1 Sensor ID 00b54a22 Battery Status 255 Signal Status 00

protocol definition is for ID to be x'FFFFFFFF' if offline. WH34 CH2 through CH8 show offline.

Stuart

As a test this morning I disabled the WH65 and WH34 and the disappeared as they should in my code. I now enabled them and now they are behaving as they should in that they show offline. This leads me to believe that when the f/w was built they left some data in for these two sensors which caused them to appear in the battery info. I wonder what else they messed up in the f/w which was distributed.

I noticed btw that they misspelled the word Cancel as Cacel on the edit option for sensor ids, minor I know but sloppy IMHO.

Stuart