Topic: WN1900 hangs after a few minutes [solved]

[wvdkuil]

For testing I ordered a WN1900 Wi-Fi Weather Station

Connected to 2.4G WiFi network (tested with multiple ones)
Can be seen by ws-view and ws-view+
Accepts WiFi credentials and is seen by WiFi tools/scanners.
Custom  upload set to 1 minute.

After maximum 4 custom uploads the device stops, is not visible  for ws-view, the scanners report "not reporting after ping"

Removing power unit and batteries + 30 seconds waiting + adding power again
=> unit starts uploading
It is then again accessible for ws-view but it fails again after a few minutes.

The unit can see a lot of extra sensors for soil, temp-hum, leaf a.s.o.
As it takes some time before all sensors are found by the unit, that could be a problem?

Tried to block the extra sensors but that takes to much time, the unit will hang in between.
Seems that restarting resets my modifications.

Does anyone else uses the WN1900 with a lot of sensors?

===

I could test the complete unit for the PWS_dashboard use, it reports no UV/solar as the outside unit is a WN67.
It reports it as a WN65.
If another outside unit is available it reports UV/solar correctly.

Also all other sensors are reported when detected until uploading stops.
It never reported all available sensors compared with the GW1000 I test with.

The WH32 is not shown in the first minutes, but after the upload stops the console shows the temp/hum sensor.
As the unit console and outside unit are on my desk, the inside and outside temps are very close in the uploaded data.

Code: [Select]

    [stationtype] => WS1900A_V1.1.8
    [dateutc] => 2022-01-16 15:03:40
    [runtime] => 62
    [tempinf] => 74.5
    [humidityin] => 34
    [baromrelin] => 30.162
    [baromabsin] => 30.162
    [tempf] => 70.3
    [humidity] => 36
    [winddir] => 195
    [windspeedmph] => 0.00
    [windgustmph] => 0.00
    [maxdailygust] => 0.00
    [rainratein] => 0.000
    [eventrainin] => 0.000
    [hourlyrainin] => 0.000
    [dailyrainin] => 0.075
    [weeklyrainin] => 0.075
    [monthlyrainin] => 0.075
    [yearlyrainin] => 0.075
    [totalrainin] => 0.075
    [temp2f] => 76.64
    [humidity2] => 29
    [temp4f] => 53.06
    [humidity4] => 46
    [pm25_ch2] => 15.0
    [pm25_avg_24h_ch2] => 15.0
    [lightning_time] =>
    [lightning_num] => 0
    [lightning] =>
    [leafwetness_ch1] => 79
    [ws1900batt] => 3.04
    [wh65batt] => 0
    [batt2] => 0
    [batt4] => 0
    [pm25batt2] => 6
    [wh57batt] => 5
    [leaf_batt1] => 1.48
    [freq] => 868M
    [model] => WS1900Wim

[wvdkuil]

Tested with 4 different 2.4bng modem/accespoints oldest one a >8 year old AirPort Extreme to newest gigabit modem.

At 2 different locations, first my appartement with all possible Ecowitt sensors, second location with only the wh65.

Uploads first with only the custom upload and second time with simultaneous  ecowitt.net and custom upload

In all cases the console stops uploading after 2 - 6 uploads.
Also it does no respond to ws-view, nor to  a ping.
The display continuous to be updated with new weather-data, also the buttons work a.s.o.
Only the uploads stop.

Removing batteries and external power unit, reinserting those => operation resumes for another 2-6 uploads.

Wim

[davidefa]

I don't have the wn1900 ( so can't anything specific about it ), but only to rule out that is not a power supply issue, you could try connecting the wn1900 to a power bank ( to see if it lives longer than 2-6 uploads )

[Rover1822]

Is there a later firmware available than the one you are using?

[wvdkuil]

I don't have the wn1900 ( so can't anything specific about it ), but only to rule out that is not a power supply issue, you could try connecting the wn1900 to a power bank ( to see if it lives longer than 2-6 uploads )

Yes it lives far longer as the screen continuous to be updated.
The uploads via wifi 2.4bgn fail as does the access from a ws-view/ws-veiw+  app

Is there a later firmware available than the one you are using?

AFAIK the device is using the latest 1.1.8, installed by ws-view first time it was seen by the app.

===
Also tested uploads to only ecowitt.net
similar problem, after 2 - 3 uploads ( 1 / minute) the WS1900A is not reachable via WiFi.

===
Without upload settings the device remains reachable via WiFi for at least 20 inutes.
If I then set upload to ecowitt back to on, the device stops responding after 1 or 2 uploads again.

Wim

[olicat]

Hi Wim,

there seems to be a newer version now - v1.19:

New Firmware WS1900V1.1.9:
1.Fixed a crash after running for 50 days.
2.Fixed an issue where uploading data stopped on some routers.

So this could help for you - give it a try. Just update via WS View/WSView Plus.

Oliver

[wvdkuil]

Hi Wim,

there seems to be a newer version now - v1.19:

New Firmware WS1900V1.1.9:
1.Fixed a crash after running for 50 days.
2.Fixed an issue where uploading data stopped on some routers.

So this could help for you - give it a try. Just update via WS View/WSView Plus.

Oliver

Yes that is the update, but my WS View/WSView Plus do not "see" that update.
Normally you should get a message, not this time.

Wim

[olicat]

Hi!

ut my WS View/WSView Plus do not "see" that update.

In fact, Ecowitt has a minor error in their update description for the WN1900, which is why this update is not recognised as a new update.
Fine Offset/Ecowitt must fix this on their server.
Perhaps you should write to Ecowitt that WS View does not update the WN1900 although a corresponding update should be available.
I am pretty sure that they will discover and fix the error quite quickly.

But maybe that's the way it's supposed to be and the release is still imminent.

Funny side note: If you had v1.17 now, the update to v1.19 would probably work.


Oliver

[olicat]

Hi!

The error has just been corrected. The v1.1.9 should now be downloadable with WS View.

Oliver

[wvdkuil]

Hi!

The error has just been corrected. The v1.1.9 should now be downloadable with WS View.

Oliver

Yes, it was updated after two corrections.
Now testing if it continues to update ecowitt and custom server.

Wim

[henry]

Hi!

The error has just been corrected. The v1.1.9 should now be downloadable with WS View.

Oliver

Hi， Oliver

You are amazing! Your reminder made this bug correction as fast as possible.  We are really appreciate your work on this.

[wvdkuil]

Hi!

The error has just been corrected. The v1.1.9 should now be downloadable with WS View.

Oliver

Yes, it was updated after two corrections.
Now testing if it continues to update ecowitt and custom server.

Wim

Now the WH1900 reported correctly for longer periodes.
Also removing the USB power the WH1900 on battery power runs in "power saving mode"
=>  continues to upload the primary  outdoor sensor.
=> uses minimal WiFi  task
=> but still can be accessed by ws-view after pressing the light button

There is one remaining "problem for some situations" in USB power mode
It always uses the data from a "nearby" WH32 temp/hum sensor.
Good feature when your own outside array has a failing T/H sensor.
Sadly on the WH1900 one can not disable the WH32 in ws-view
So a nearby WH32 always replaces the WH1900 outside temp/hum even when the "neighbours" WH32 sends "intermittently" or sends garbage.

Systems should be build that:
Never a sensor can overwrite a primary sensor without allowing the station-owner to disable a "foreign" sensor.

There are two sensors which should be better supported:

• inside temp/hum/pressure sensor standard with a HP2650 or 2551 console
• outside "main" temp/hum sensor often used with separate wind / rain sensors

All "consoles" should be allowed to select such a sensor if those special sensors are  found
All "consoles" should be able to disable such a sensor as their own primary sensor is better.

Why: One real-life example discussed on this forum a few days ago.
A GW1000 is placed as near to the outside sensors as possible.
But that often is the wrong place for "inside temp/hum" which is integrated with a cable to the GW100/GW1100/GW2000

Even if you use a T/H/P the GW1000 refuses to acknowledge its existence.
That is why @olicat's code and my receiving code can use a normal extra sensor to replace the "integrated"inside or outside  sensors.
Those settings belong in the ws-view setup directly at the source of receiving the weather-values.
That way we make sure that weather-data uploaded to external sources all have the same values.

Wim

[olicat]

Hi!

Systems should be build that:
Never a sensor can overwrite a primary sensor without allowing the station-owner to disable a "foreign" sensor.

There are two sensors which should be better supported:
inside temp/hum/pressure sensor standard with a HP2650 or 2551 console
outside "main" temp/hum sensor often used with separate wind / rain sensors

All "consoles" should be allowed to select such a sensor if those special sensors are  found
All "consoles" should be able to disable such a sensor as their own primary sensor is better.

I fully support that!
Since WH2650 and GW1000 use the identical firmware, this should be easy to implement.
You just have to check if there is data via I2C (then it is probably a GW1000) and then check if the WH32B is disabled or not.
If the WH32B is disabled, the I2C data is taken over. Otherwise, the data of the WH32B are taken over as internal values.
The same procedure can and should be used for the WN1900.
And of course a WH32 should also be deactivatable. For all stations available. Also easy to implement.

So Ecowitt: can we hope for that in the near future?

Oliver

[henry]

Hi!

Systems should be build that:
Never a sensor can overwrite a primary sensor without allowing the station-owner to disable a "foreign" sensor.

There are two sensors which should be better supported:
inside temp/hum/pressure sensor standard with a HP2650 or 2551 console
outside "main" temp/hum sensor often used with separate wind / rain sensors

All "consoles" should be allowed to select such a sensor if those special sensors are  found
All "consoles" should be able to disable such a sensor as their own primary sensor is better.

I fully support that!
Since WH2650 and GW1000 use the identical firmware, this should be easy to implement.
You just have to check if there is data via I2C (then it is probably a GW1000) and then check if the WH32B is disabled or not.
If the WH32B is disabled, the I2C data is taken over. Otherwise, the data of the WH32B are taken over as internal values.
The same procedure can and should be used for the WN1900.
And of course a WH32 should also be deactivatable. For all stations available. Also easy to implement.

So Ecowitt: can we hope for that in the near future?

Oliver

Yes, good idea. will think about this request.