Topic: new firmware version for GW2000: V2.2.3

[Platokidd]

Since updating to v2.2.3 I've noticed issues.
Using Ethernet only and wifi switch off.

1-When on ip setting DHCP the gw2000 broadcast and can be seen on any device searching for wifi.
2-When on static ip and after rebooting the gw2000 it is hidden from wifi on other devices.
However, no data can be seen on WU or weather cloud. Ecowitt works fine.

Before the updating both my gw2000's work fine. Now if I want to hide from wifi I need to use static ip. However, no weather services work.

Will dig more into to this later.....

Go to GW2000 settings (via web browser or app)
Select "Local Network" and set address modes foe Eth and WIFI to DHCP
Then go to "Device Settings" and Disable the gateway's self broadcasting SSID
Don't forget to click "Apply"

That was my setting to start with before and after the upgrade. All I did was hit the wifi switch off. However now it seems to be working again. Fingers crossed..
Thanks for reply

[wsNoordbergum]

Got my new GW2000 delivered last
Set it up and worked great out of the box
BUT updated the firmware and then trouble again.....
Seems the latest firmware is not very stable for the GW2000
Same symptoms with the new device
But I solved it via the WSview plus app
It seems the network the GW2000 creates when starting up is not stable somehow, also a wired LAN connection is not a good idea because it really does not connect to my internet properly, the stack does not seem to load properly
Some pages on the device are not created
With the WSview plus app setting the GW2000 up went well and it works now, also my old GW2000 functions properly now, so I have two now....
My first WS90 was also registering rain when it was dry, I decided to go back to FW version 1.1.9 and it changed the behavior not significantly, still spikes in rainrate but power management is better now
The capacitor is now charging as it should and after the firmware upgrade, the voltage suddenly rose with 0.5v
Strange but it charges up to 5.3 volts now which is the maximum capacity
Time to figure out why the spikes happen, it has to be a hardware issue and not interfernce of some kind.

[Gyvate]

I cannot confirm an unstable LAN connection with my GW2000s - was working properly all the time and still is.

With FW 2.2.3 there seems to be some issue with remembering the original static LAN IP, especially after a power-cycle or reboot.
It then brings in a DHCP provided IP different from the original one claimed to be static.
Trying to change this unwanted IP brings back the former IP (the new one to be changed).
To solve the issue the IP has to be set to DHCP and saved. Then interface needed to be left and reconnected and the IP newly set up as static. Then it holds the information and runs in a stable manner.

[hiljo]

I cannot confirm an unstable LAN connection with my GW2000s - was working properly all the time and still is.

Same here. No problems with this firmware version.

[Avise]

With FW 2.2.3 there seems to be some issue with remembering the original static LAN IP, especially after a power-cycle or reboot.
It then brings in a DHCP provided IP different from the original one claimed to be static.
Trying to change this unwanted IP brings back the former IP (the new one to be changed).
To solve the issue the IP has to be set to DHCP and saved. Then interface needed to be left and reconnected and the IP newly set up as static. Then it holds the information and runs in a stable manner.

Yup, had the same problem and stumbled upon the same solution by trial and error. Set it back to DHCP, saved, set it to static again and it kept the static address.

[BaseLine]

I cannot confirm an unstable LAN connection with my GW2000s - was working properly all the time and still is.

With FW 2.2.3 there seems to be some issue with remembering the original static LAN IP, especially after a power-cycle or reboot.
It then brings in a DHCP provided IP different from the original one claimed to be static.
Trying to change this unwanted IP brings back the former IP (the new one to be changed).
To solve the issue the IP has to be set to DHCP and saved. Then interface needed to be left and reconnected and the IP newly set up as static. Then it holds the information and runs in a stable manner.

Set the static address from your wifi-router (what ever you have there) running the DHCP server.

Your device MAC - static IP.

If for some reason you cant do that (too many devices? Get a better router), increase the IP lease time. It means that if your device goes down for X time, it will get the same IP address.
If you think you really need to set static IP from the device, make sure it's not from your DHCP's address pool.

If none of this makes sense to your, you should not be screwing around with static IP's to begin with.

[SamiS]

Set the static address from your wifi-router (what ever you have there) running the DHCP server.

Your device MAC - static IP.

If for some reason you cant do that (too many devices? Get a better router), increase the IP lease time. It means that if your device goes down for X time, it will get the same IP address.
If you think you really need to set static IP from the device, make sure it's not from your DHCP's address pool.

If none of this makes sense to your, you should not be screwing around with static IP's to begin with.

Sorry but as a professional network administrator I just have to rant about the terminology.

Static ip address means that there is no dhcp protocol and neither a dhcp server involved at all. With static ip addresses you can get two or more devices communicating with each other through a switch even without a router present at all.

What you are referring to is a dhcp reservation or dhcp binding that is done on a dhcp server (or on a router acting as one). In this case you bind a mac address to a specific ip address, so it will not change anymore even if the address lease is expired during disconnection. Functionally it is ”static” yes, but it is still assigned by dhcp, and if the dhcp server fails, the device can lose its address and network connectivity. On current Asus routers this feature is referred as ”Manually Assigned IP”, but other vendors can have it some other way.

[Rover1822]

I agree totally.
Also you have to know the device that you have reserved an IP for. In the case of these devices , their MACs , are static. I as mentioned previously, I prefer to static at the device as opposed to reserving an IP based on MAC at the router.

There is a very strong movement to randomize MAC addresses , I know my phone does that by default (which I turned off as I need to see it), and I have no doubt that will percolate to other devices, over time.

The other benefit to static at the device, is if you need to replace your router, if you know your statics, then no issue.

 

[SamiS]

There is a very strong movement to randomize MAC addresses , I know my phone does that by default (which I turned off as I need to see it), and I have no doubt that will percolate to other devices, over time.

Mac randomization is a good technology to prevent tracking your device between several public wifi networks. But actually the address is not constantly randomized again and again, so it is not such a big deal. When you connect to a wifi network and save it to known networks, at that moment the randomized  mac address is also saved on your device to be used every time you connect to that specific network. So actually you can do a dhcp binding on your router to a randomized mac address and still get the same ip unless you make your phone forget that network. Edit. Of course the binding must be made to the randomized mac (not the native one) that can be checked from device’s wifi settings under known networks.

Also due to randomization being a countermeasure to tracking user between networks, it is very likely that mac randomization never will spread to cabled connections since mac address is only visible for the first layer 2 lan segment.

[BaseLine]

Sorry but as a professional network administrator I just have to rant about the terminology.

Static ip address means that there is no dhcp protocol and neither a dhcp server involved at all.

Sorry, but you are not right.     IP address allocated by DHCP server etc can be either a static addresses, meaning that the device Z will always have the same IP address or a dynamic (can change) IP. Assigned manually at the device or by the DHCP will not change definition.

Logging into multiple devices to set IP addresses or to log into one and set the addresses for all... not a tough choice, is it Added bonus - you have a list of what is wnat and it's always up to date.

[Gyvate]

your wording seems to suggest that static IP addresses can be only assigned by a DHCP server - which would not be correct.
You can define a static IP range in a DHCP server, but the majority of network admins do not advise this approach.
Good practice is considered to define the dynamic IP range inside the DHCP server and let the DHCP server not be aware of the remainder of the available subnet addresses which form the static range. Inside the DHCP server assigned IP range you can also create quasi-static IP addresses by MAC binding.

If a device gives itself a static IP address outside the DHCP assigned IP range, it will be valid, reachable and routable (as long as it is inside the subnet definition and neither the gateway (aar the router/switch) nor the broadcast address).
In the big IT world static IP addresses (mostly not handled by a DHCP server) are the default and dynamic IP addresses are the exception - for good reasons not to be explained here. And they are set in the NICs of the servers or other network devices.

[BaseLine]

your wording seems to suggest that static IP addresses can be only assigned by a DHCP server - which would not be correct.

Nice straw-man. I said no such thing.

You can define a static IP range in a DHCP server, but the majority of network admins do not advise this approach.

Static IP range? Again, I said no such thing. You really like your straw-mans, don't you

[Gyvate]

You can define a static IP range in a DHCP server, but the majority of network admins do not advise this approach.

Static IP range? Again, I said no such thing. You really like your straw-mans, don't you

not sure if you are a native English speaker - or know that language thoroughly ....
"you" in such a context means "(some)one" and not "you personally" ....
so no straw men involved here

[SamiS]

Sorry, but you are not right.     IP address allocated by DHCP server etc can be either a static addresses, meaning that the device Z will always have the same IP address or a dynamic (can change) IP. Assigned manually at the device or by the DHCP will not change definition.

I have to argue, you missed the point here.

When you configure a static ip address to a device, by the definition it is not something that is assigned by Dynamic Host Configuration Protocol.

Yes, you can define an ip reservation to dhcp server, and that will ensure that the device ip address remains the same and does not change, so it is ”static” in that way. But technically it is still not a static ip by definition.

IP addresses are assigned to a host either dynamically as they join the network, or persistently by configuration of the host hardware or software. Persistent configuration is also known as using a static IP address. In contrast, when a computer's IP address is assigned each time it restarts, this is known as using a dynamic IP address.

https://en.wikipedia.org/wiki/IP_address#IP_address_assignment

[kheller2]

Sorry but as a professional network administrator I just have to rant about the terminology.

Static ip address means that there is no dhcp protocol and neither a dhcp server involved at all.

Sorry, but you are not right.     IP address allocated by DHCP server etc can be either a static addresses, meaning that the device Z will always have the same IP address or a dynamic (can change) IP. Assigned manually at the device or by the DHCP will not change definition.

Logging into multiple devices to set IP addresses or to log into one and set the addresses for all... not a tough choice, is it Added bonus - you have a list of what is wnat and it's always up to date.

Okay, I'll get on my pony and play too.

IP Addresses assigned via DHCP or BOOTP or whatever are DYNAMIC. They are Dynamically assigned because the device itself does not have a statically assigned address in its hardware/software.  It uses the "Dynamic Host Configuration Protocol" (it's in the name) to assign an address to a device.  We all agree on that.

You can however configure DHCP to assign fixed addresses/Reserved leases to specific devices.  This is NOT static assignment. 

In your example above, device Z will NOT always have the same address even if you set up reservations under a variety of conditions:  Can't reach DHCP server, DHCP server down, you took device to your friend's house, and so on.

I don't want to use the phrase "manually assigned" because technically you manually assign it weather you configure it as a reservation or as a static address on the device itself.

Bottom line: A statically configured address is static and depends on nothing else.  It will always be what you set it to no matter how poorly one's network is built. (Well, in most cases, because some will ARP for the address before assigning the address to the NIC to see if is already in use and then will refuse to assign it even to itself).

Having said all that --- yes having reserved leases in your DHCP server for your devices does have advantages.  But then so does running your own DHCP, DNS, NTP, etc services on another box.  To each their own.

Newbies:  Just write down on a list what IP you put where, or track it on your reservations list on whatever you own that provides DHCP services.

[BaseLine]

TLDR:  Hyperbole infused straw-man meets jazz hands, presented as a dynamic mental gymnastics dance therapy.
 
A novel idea: Please go outside and touch grass

[umbra]

Hello.

Background:
I have a WS90 and WH40 rain gauge and have been tracking the two for over a year (feeding into Weewx)
I use the "Customized" option on the GW2000 to send ecowitt format to a logger which I then forward - key point is that I have a record of the data stream.

Potential Issue
I upgraded the GW2000 firmware a couple of days ago and since then the piezo rain data has been zero according to the GW200 web interface and the data sent to the logger, while the WH40 is recording the rain (it's raining now)

Can anyone offer suggestions? Coincidence perhaps?
the WS90 is mounted quite high so am loathe to do a visual check/firmware update unless other no other option

WS90 FW v1.1.7

[broadstairs]

On my GW1100 in wsview+ under rain there is an option to set the default rain gauge to be uploaded, I assume the GW2000 has the same what is it set to?

Stuart

[Gyvate]

I guess you mean the "Rain Totals" page in WS View Plus.
It is set - in your gateway (GW1x00, GW2000 etc.) to whatever you set it.
If it is set (by you or by factory delivery default) to "traditional", you can calibrate the traditional rain gauge, provided one is connected (WS69, WS40)
if it is set to "piezo", you can calibrate the WS90 rain tiers. (same inside the HP25x0 consoles)
Whichever priority is set, the ecowitt.net dashboard displays both if both are connected (as does WSView Plus on the "Live Data" page).
One as "Rain[fall]" (default name) and one as "Piezo" (default name).
Maybe in the default tile sequence, the traditional tile comes first when traditional is selected (but you can change your tile sequence).

If your HP25x0/HP350x console has "traditional" selected, only the traditional rain gauge data is displayed on the screen and sent to  the ecowitt.net dashboard.

But you have to be careful depending on your needs - if e.g. you want to get the wind or solar readings of the WS69 or WS80 and the rain readings of the WS90, that's not possible - the WS90 has highest wind, rain, solar reading priority. Then you need two consoles/gateways.
 
The settings are identical in the WebUI under "Rain Totals" (for those consoles which have a WebUI beyond WiFi setup)

[umbra]

Thanks for the replies.

I should clarify that:

• I use the built-in web interface of the GW2000 which shows both "Rain" and "Piezo Rain".
• I don't use any apps
• My data goes into a local weewx instance (see profile).

It rained again today: 1.4mm on the WH40; 0.1mm on the Piezo reader.
For the past year, the piezo has reported about 5% higher than the WH40 using default calibration (1.0) so I conclude that something is amiss.

My guess is either:
Firmware update is coincidence and the piezo may need a clean, or
The GW2000 firmware has "adjusted" the calibration values

Given that no-one else has reported GW200 firmware issues, I may have to look to clean and update the WS90 firmware...

[broadstairs]

There is a setting on the web interface for default rain gauge just as there is on the app. You do need to check that setting on there just in case it is wrong.

Stuart

[Gyvate]

My guess is either:
Firmware update is coincidence and the piezo may need a clean, or
The GW2000 firmware has "adjusted" the calibration values

the console/gateway (here your GW2000) doesn't do any adjustments to the rain sensor readings (unless you tell it to do so via calibration settings)
=> changes in reading behaviour only go via the WS90 i.e. its firmware.

There had been several changes (upgrades) in the WS90 firmware, some pertaining to the wind readings, some to rain readings.
Have a look at https://www.wxforum.net/index.php?topic=40730.0 
Whatever rain calibration you make for the WS90 (5 linear tiers - gain factors), it may need to be corrected after a sensor firmware upgrade.

The non-linear behaviour of the WS90 rain gauge especially at low rain rates or with strong windy rainfalls  is a known issue - there is a "Wittboy" thread here in the forum which fills pages
https://www.wxforum.net/index.php?topic=43139.0
we keep on getting repetitive posts in that area ...