WXforum.net
Weather Station Hardware => Ambient Weather and Ecowitt and other Fine Offset clones => Topic started by: HansR on December 31, 2021, 04:36:54 AM
-
Please note my description on the CumulusMX forum (https://cumulus.hosiene.co.uk/viewtopic.php?p=159711#p159711).
[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)
-
@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 ?
-
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
-
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 ...)
-
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 ;)
-
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.
-
Is there any possibility that someone else has a similar system nearby?
-
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.
-
Is there any possibility that someone else has a similar system nearby?
No, not within 100m
-
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 ;)
-
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 ]
-
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 :-)
-
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).
-
@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 )?
-
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
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 ]
-
@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
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.
-
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
-
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.
-
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
-
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.
-
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 ...
-
@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
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
-
@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
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
-
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.
Yes, supposedly sunny south somerset.
1960s detached, overhead power lines and telecom, Main ring plus additional spurs. had the mess of fuses replaced with a breaker box when we moved in.
The timings of the temp spikes have been random. But they've generally been at night.
Main suspects freezer, fridge, and connected devices phoning home (including the gateways)
i had overlaid the fridge and freezer temperature plots against the WS80 temp spikes, with no correlation.
I also checked router for any devices phoning home, again the timings don't match.
Longest stable run has been 86.5 Hrs.
Currently at 54Hrs
I plan on leaving as is for another 5 days (unless I see another spike).
If all is well, I will swap the outdoor T & H assignments between the Gateways.
Next step will be to disable all the Sensors on both Gateways, Then enable them one by one, editing the ID against the CH number as I go.
This will have the advantage (for me) of standardising the configuration on both Gateways (with the exception of the WH32EP).
The last step will have an added complication for me. In that, I maintain a history record in Excel, by copying the daily data table from ecowitt.net, and a bit of VBA to update my log and charts.
I'll need to transpose columns and edit a few lines of the code.
When I can eventually get a console, I'll see if the 2 SD card method is more suitable.
-
..............
I plan on leaving as is for another 5 days (unless I see another spike).
If all is well, I will swap the outdoor T & H assignments between the Gateways.
Next step will be to disable all the Sensors on both Gateways, Then enable them one by one, editing the ID against the CH number as I go.
This will have the advantage (for me) of standardising the configuration on both Gateways (with the exception of the WH32EP).
The last step will have an added complication for me. In that, I maintain a history record in Excel, by copying the daily data table from ecowitt.net, and a bit of VBA to update my log and charts.
I'll need to transpose columns and edit a few lines of the code.
When I can eventually get a console, I'll see if the 2 SD card method is more suitable.
If you are ready to have e.g. a RaspberryPi running 24/7 (runs on Linux and Windows 11), you could think of using CumulusMX free weather software (also runs on Linux and Win11) and have your data logged at your chosen interval (1 minute to ....), independent of ecowitt.net downloads. It creates logging interval based CSV files which you can work on in Excel if its reporting features are not sufficient for you.
-
I plan on leaving as is for another 5 days (unless I see another spike).
If all is well, I will swap the outdoor T & H assignments between the Gateways.
Next step will be to disable all the Sensors on both Gateways, Then enable them one by one, editing the ID against the CH number as I go.
This will have the advantage (for me) of standardising the configuration on both Gateways (with the exception of the WH32EP).
The last step will have an added complication for me. In that, I maintain a history record in Excel, by copying the daily data table from ecowitt.net, and a bit of VBA to update my log and charts.
I'll need to transpose columns and edit a few lines of the code.
When I can eventually get a console, I'll see if the 2 SD card method is more suitable.
Interesting program.
You could automate the backup of station's data using the 'custom upload' option of the gateways to send data to a small php script ( you can use one free hosting service available, for example if you don't have already one ).
I do it using meteotemplate ( it can do a lot more ) as you can see in my signature.
-
Slightly off topic, but I feel it's best answered here.
My reason for having a weather station is primarily to monitor growing conditions, both in my garden and my greenhouses.
It has taken over 12 years to take the plunge.
Until I stumbled across the ecowitt gateway solution (thanks to the cumulus forum), the closest would have been a VP2 with additional leaf and soil stations feeding wifi logger or meteobridge pro or raspberry PI My Unix/Linux experience is extremely rusty).
I could never justify that sort of cost to myself. Hence I found the ecowitt solution and its expandability extremely promising.
I spent a long time going back through this forum, particularly the WS80 saga and the current WS90 saga, and have been impressed by both the quality of posts and the fact that ecowitt have developed the products accordingly.
I like to have full possession of my data, and the ability moving forward, to easily compare say June 2022 and June 2023 conditions.
My spreadsheet is set up with that in mind (I might over time migrate to an access database).
I'm hard of hearing, hence my requirement for a console with visual alarms.
Moving forward I'm still considering a Meteobridge or PI. I have Cumulus MX installed on WIN 10.
I need to investigate the meteotemplate option.
Thanks to all for a brilliant forum
-
Gateway2 Showed a 60 Deg C temp from 1:00 AM to 2:00 AM UK time last night.
All other readings OK and No new spurious battery.
I think I need to upgrade the firmware on the WS80 before any further action.
-
After several mail exchanges with Ecowitt with some misunderstandings, they advised me:
- To use WsView Plus (so I installed it beside plain WsView)
- And in WsView Plus in the Sensors ID list the top one is WS90
- Disable WS90 (:!:)
So I presume it is a current firmware problem when both WS80 and WS90 are enabled and 'learning'.
We'll see what this brings. I agreed a max of two month before concluding a fix.
Other explanation with this instruction is minimal but they claim it solves the issue.
And who knows, maybe it is better to disable all unused sensorID entries (it avoids at least the permanent learning which no doubt takes valuable value reading time).
-
After several mail exchanges with Ecowitt with some misunderstandings, they advised me:
- To use WsView Plus (so I installed it beside plain WsView)
- And in WsView Plus in the Sensors ID list the top one is WS90
- Disable WS90 (:!:)
So I presume it is a current firmware problem when both WS80 and WS90 are enabled and 'learning'.
We'll see what this brings. I agreed a max of two month before concluding a fix.
Other explanation with this instruction is minimal but they claim it solves the issue.
And who knows, maybe it is better to disable all unused sensorID entries (it avoids at least the permanent learning which no doubt takes valuable value reading time).
HansR
I'm not qualified to dispute Ecowitt's advice. However, for me, swapping the location of the 2 gateways (8 metres of seperation) stopped a recurrence of the issue.
I do still have an issue with the WS80 T & H. This reoccurred this morning, so I swapped the 2 gateway assignments. And another spike followed the assignment change.
So I'm confident that both gateways are behaving.
I have now disabled all unused sensors, as a further precaution.
-
After several mail exchanges with Ecowitt with some misunderstandings, they advised me:
- To use WsView Plus (so I installed it beside plain WsView)
- And in WsView Plus in the Sensors ID list the top one is WS90
- Disable WS90 (:!:)
So I presume it is a current firmware problem when both WS80 and WS90 are enabled and 'learning'.
We'll see what this brings. I agreed a max of two month before concluding a fix.
Other explanation with this instruction is minimal but they claim it solves the issue.
And who knows, maybe it is better to disable all unused sensorID entries (it avoids at least the permanent learning which no doubt takes valuable value reading time).
This is exactly what I was asking for ( disabling the autolearning ), I didn't understand it was already present ( well a little hidden ).
You have to disable every single sensor you do not want.
Thanks for sharing
-
This is exactly what I was asking for ( disabling the autolearning ), I didn't understand it was already present ( well a little hidden ).
You have to disable every single sensor you do not want.
Thanks for sharing
OK. We are not yet certain that this is the definitive solution, we have to wait further communication which I'll report.
I also asked Ecowitt to disable all sensors by default i.s.o. enable. No response yet.
-
OK. We are not yet certain that this is the definitive solution, we have to wait further communication which I'll report.
I also asked Ecowitt to disable all sensors by default i.s.o. enable. No response yet.
You are one of those that can confirm if this is a good solution ( having the problem of 'ghost sensors' ).
For now I'm happy not seeing the 'learning...' anymore ( and quite confident this is a good thing ).
As for the 'autolearning' default status I think it should be enabled ( so not to upset every new user ), but they should write somewhere:
'WARNING: DISABLE ALL UNUSED SENSORS AS SOON AS POSSIBLE OR EVERY NASTY THING MAY HAPPEN TO YOU...' ( or something like that ; - ).
Wondering why keeping it 'so secret' ( as we are not the only one who didn't understand this )?
-
The ball is now in Ecowitt's court, so we wait.
At every communication with Ecowitt which says something about this issue I will communicate here.
As it is a very irregular issue I proposed a two month delay before we accept it as a true solution.
So if the problem occurs with you while having sensors disabled (and certainly the WS90) report here as well.
-
Yes these 'sporadic issues' are very difficult to pinpoint.
It's not uncommon that you think the problem solved, but it reappears as you 'turn your back'.
So a couple of month delay may be a reasonable amount of time.
-
NOTE: the issue does not seem to be resolved by disabling all sensors not used.
Check out this observation (https://cumulus.hosiene.co.uk/viewtopic.php?f=42&t=20134) (image reproduced below, for more you will need an account there).
The issue seems to be again with the GW1100.
I would advise a reboot every 4 weeks to avoid issues?
I notified Ecowitt.
(https://cumulus.hosiene.co.uk/download/file.php?id=22400)
-
NOTE: the issue does not seem to be resolved by disabling all sensors not used.
Check out this observation (https://cumulus.hosiene.co.uk/viewtopic.php?f=42&t=20134) (image reproduced below, for more you will need an account there).
The issue seems to be again with the GW1100.
I would advise a reboot every 4 weeks to avoid issues?
I notified Ecowitt.
(https://cumulus.hosiene.co.uk/download/file.php?id=22400)
what version of ws80 do you have? If you have the latest version with sht40 detachable sensor you need to update the firmware (1.2.0).
-
I feel this is getting a bit confusing (not too difficult when one is approaching 70).
The original issue was 2 gateways ( I also have 2 gateways and a HP2550 console as well).
I also now run MX on a Synology NAS and Weewx on a PI.
The screen grab is from another user (Hoeveld).
This could be a separate issue.
Are you yourself still getting spurious results ( the additional battery info will never IMO disappear from Ecowitt.net database. I deleted my devices and re added them to tidy mine up).
Not recommended if you do not have other backups of your data.
To update on my similar issues.
Since swapping the location of my 2 gateways and disabling unused sensors I have no errors unique to one gateway.
I did continue to have sporadic spikes in Temp and Solar values from the WS80 (If only I could really generate solar power at 3:00am)
However these errors were also duplicated on the HP2550 console.
Ecowitt have now replaced the WS80 after interrogating their database against my IDs.
The last firmware, was specific to temperature spikes on the latest hardware. My hardware was confirmed by Ecowitt to be an older version.
I would suggest you recommend that Hoeveld email support@ecowitt.net with his index?id, they were extremely helpful in my case.
-
I feel this is getting a bit confusing (not too difficult when one is approaching 70).
The original issue was 2 gateways ( I also have 2 gateways and a HP2550 console as well).
I also now run MX on a Synology NAS and Weewx on a PI.
The issue is very similar so I chose to add it to the thread. And I informed Ecowitt as well. It is a very new device and their reaction was that the issue was caused by droplet formation. I disagree with that because the temperature was around 9 degrees C and a storm was raging with windspeeds up to 50 mph. Not a droplet forming condition.
The screen grab is from another user (Hoeveld).
This could be a separate issue.
See above why I chose to add it.
Are you yourself still getting spurious results ( the additional battery info will never IMO disappear from Ecowitt.net database. I deleted my devices and re added them to tidy mine up).
Not recommended if you do not have other backups of your data.
I don't mind the erroneous device being in Ecowitt.net, I do mind having these data errors. So far (four weeks now) I have not had such errors but I agreed with Ecowitt to see for two months
To update on my similar issues.
Since swapping the location of my 2 gateways and disabling unused sensors I have no errors unique to one gateway.
So how long is that?
I did continue to have sporadic spikes in Temp and Solar values from the WS80 (If only I could really generate solar power at 3:00am)
However these errors were also duplicated on the HP2550 console.
Ecowitt have now replaced the WS80 after interrogating their database against my IDs.
The last firmware, was specific to temperature spikes on the latest hardware. My hardware was confirmed by Ecowitt to be an older version.
I would suggest you recommend that Hoeveld email support@ecowitt.net with his index?id, they were extremely helpful in my case.
It is not spikes which are the problem in this thread, it is the failure of acquiring data.
And beside that: my first post explains it was not the WS80 which caused the issue but the GW1100. And that still stands. The point of showing the latest case is that with all not used sensors switched to disabled, acquisition errors may still occur.
-
My point, is that this could be a WS80 communication problem.
My gateways were swapped on 01 Jan
-
to be precise it could be a WS80 transmission issue (the "communication" is only one way, the array transmits and doesn't even know if and by whom (which device, console, ...) it is received.
But the transmissions can also be disturbed by other devices transmitting at 868 MHz (or 433 MHz). So if the signal is disturbed, the console will only receive "rubbish" and will record/post it.
Typical devices are remote controls for cars, automatic garage doors, gates etc. Nowadays the list of such devices can be long. They all use the public 868 MHz range.
You would be astonished what is all "flying" around, if you used a SDR-433 device (just the name, also reeives at 868 MHz).
You may live in the country side with no (doesn't exist, let's say little) technology around, but a visitor, passer-by with their car etc. can be also the culprit.
So it may not always be the weather device's fault...
If it doesn't occur systematically and repeatedly, it may just be like a satellite transmission distortion by some atmospherics.
-
@Gyvate: I think we agree that it can be a lot of things if not anything. But:
- I live in an area without this technology within range so I exclude disturbance for my situation
- I take the point of view that the GW1100 must detect disturbances and anomalies and simply reboot if in dire straights. That should not be too hard (read the story of the guidance computer of the Lunar Module while descending to the moon)
I don't think it is the sensor, if it is a transmission failure the GW1100 should just skip the message and not hang or otherwise fail.
Continue whatever happens is the sacred word here.
-
So after some small 5 months I close this issue as far as I am concerned. I updated the firmware to 1.2 and had no flat lining since.
With respect to the values received from the device the following:
- It is on a pole 3 m above ground in an open space without buildings around in 50 m (completely free to the north, 40 meter from my house in the south). Visible on my meteocam. I gave it a correction factor of 1.2
- The values seem much more volatile than from a cup anemometer. I explain this through the inertia present in the cup anemometer (increased when the anemometer gets dirty and 'spidered').
- Because of the extreme sensitivity for air movement the sensor hardly ever reaches a value of zero average windspeed over 10 minutes.
In general: after getting used to the device, the 'flatlining' disappeared and having checked the values of the windspeed and the reasonability of the values to my own experience and stations around the area, I gained confidence and accept it as a good device.
The volatility really requires getting used to.
-
@HansR:
not only has a traditional cup anemometer a certain intertia to overcome before it starts turning, they also measure/record only 2-dimensionally, wheras ultrasonic anemometers measure 3-dimensionally. They (the ultrasonics) also consider simply speaking vertical airflow and turbulences (in fact the full range of tensors/vectors the additional dimension offers). Therefore, beyond the mechanical inertia of the cups, measurable airflow can occur which however wouldn't move the cups, while the ultrasonic anemometer would record them.
So it's very likely not so much the volatility of the sensor but rather the volatility of the real-world air(flow).
Another thing you still could do (e.g. when doing some maintenance on the WS80) is taking it into a windless space and see if there is still some airflow recorded. If so, you could calibrate it by pressing the CAL button (next to the RESET button) for 5-10 seconds until the blue LED returns into its normal flashing mode. Like this you would set a new zero baseline.
We had this phenomenon with some WS90 devices during the beta tests. They would show wind inside a closed box :roll: - and this needed to be corrected by that process. It's the same process for a WS80 as the anemometers have basically a very similar architecture. But I suggest to do it only if you consider it necessary after assessing its behaviour in a wind-free space (e.g. inside a closed cardboard box).
-
@HansR:
not only has a traditional cup anemometer a certain intertia to overcome before it starts turning, they also measure/record only 2-dimensionally, wheras ultrasonic anemometers measure 3-dimensionally. They (the ultrasonics) also consider simply speaking vertical airflow and turbulences (in fact the full range of tensors/vectors the additional dimension offers). Therefore, beyond the mechanical inertia of the cups, measurable airflow can occur which however wouldn't move the cups, while the ultrasonic anemometer would record them.
So it's very likely not so much the volatility of the sensor but rather the volatility of the real-world air(flow).
Yes, I understand. The volatility of the real-world airflow is what I meant.
Another thing you still could do (e.g. when doing some maintenance on the WS80) is taking it into a windless space and see if there is still some airflow recorded. If so, you could calibrate it by pressing the CAL button (next to the RESET button) for 5-10 seconds until the blue LED returns into its normal flashing mode. Like this you would set a new zero baseline.
We had this phenomenon with some WS90 devices during the beta tests. They would show wind inside a closed box :roll: - and this needed to be corrected by that process. It's the same process for a WS80 as the anemometers have basically a very similar architecture. But I suggest to do it only if you consider it necessary after assessing its behaviour in a wind-free space (e.g. inside a closed cardboard box).
Tbh, as the calibration to wind-free situations would be the same everywhere in the world I would expect Ecowitt to deliver the device with that being done. You do it once in laboratory conditions and its done to be put in the firmware.
-
Tbh, as the calibration to wind-free situations would be the same everywhere in the world I would expect Ecowitt to deliver the device with that being done. You do it once in laboratory conditions and its done to be put in the firmware.
Don't kill the messenger - they probably should, but still a few units in the beta testers' team needed re-calibration. Whether is was sub-optimal quality control at the Ecowitt end or something else is difficult to say. After re-calibration the units worked properly.
-
probably also on the ws80 (with 1.2.1 fw) there is a problem on <gust> values calculation. I'm currently study the situation on ws90 (same anemometer of ws80)