Warning: session_start(): open(/tmp/sess_c954c26101bff6e004b6c25712d3c49b, O_RDWR) failed: Disk quota exceeded (122) in /home/meshkaeu/www/www/Ecowitt/dokuwiki/inc/init.php on line 273

Warning: session_start(): Failed to read session data: files (path: /tmp) in /home/meshkaeu/www/www/Ecowitt/dokuwiki/inc/init.php on line 273

Warning: Cannot modify header information - headers already sent by (output started at /home/meshkaeu/www/www/Ecowitt/dokuwiki/inc/init.php:273) in /home/meshkaeu/www/www/Ecowitt/dokuwiki/inc/auth.php on line 536

Warning: Cannot modify header information - headers already sent by (output started at /home/meshkaeu/www/www/Ecowitt/dokuwiki/inc/init.php:273) in /home/meshkaeu/www/www/Ecowitt/dokuwiki/inc/actions.php on line 42
faq2 [Wiki - Fine Offset Ecowitt Ambient Weather Stations (and clones)]

User Tools

Site Tools


faq2

Table of Contents

Troubleshooting

Main WiKi - Troubleshooting overview here

overview


————————————————————————————————————————————————————————————————-

cannot connect to WLAN/WiFi

see connect to WiFi


————————————————————————————————————————————————————————————————-

sensor (array) doesn't (seem to) provide data

  1. make sure the console/gateway has proper reception (change location, look for EMI, don't place it close to a computer etc. - also power-cycling the console may help (disconnect from electricity and reconnect - in case of a WS2320/WS2910/WS3800 and WS39x0 console remove backup batteries first)
  2. are the batteries still good (not so much with arrays but with single sensors) ? - try to replace them with fully charged batteries
  3. sensors from array don't provide data - see sensor arrays
  4. in case of a WH65/WS69 sensor array, if a reset (warm or cold - for the meaning of this, see the link before) doesn't help, there is a possibility that the supercapacitor has given up its ghost. How to repair a defective super-capacitor of a WS69 in such a situation, follow the link.
  5. in case of a WS80 sensor array (Ambient WS5000-ARRAY) - if the reset of the array (see link under 3.) doesn't solve the problem, it can be that only the T/RH sensor is defective. As it shares the data bus with the solar sensor, these readings will not be shown either - only wind. Just unplug the T/RH sensor (newer models type2 and type3 –> WS80 - with older type1 models you have to follow the flat cable which ends in a plug) after having removed the radiation shield (two Philips screws) and the solar readings should re-appear.
    Get yourself a replacement sensor from shop.ecowitt.com –> accessories - it may be located under WS69 or WS80 there; the pluggable T/RH sensors are the same*. If it's still a type1 array, contact support@ecowitt.com or in case of a WS5000-ARRAY Ambient support for a replacement item.

    *) (you may even think of getting you an extra precision sensor (SHT35) instead 8-) )


————————————————————————————————————————————————————————————————-

absolute and relative pressure are the same

unless you are located at sea level, look up the section how to calibrate the air pressure of your console

————————————————————————————————————————————————————————————————-

ghost sensors

your console either shows sensors you do not have or shows sensor values which don't seem to be consistent with your micro-climate

your console may receive signals from a neighbouring station (300 - 500 m radius around your console location)
It is generally GOOD PRACTICE to actively DISABLE all sensors you do not use with your console (HP2550, GW1x00, WH2650, GW2000, GW3000, WN182x, WN19x0, WS39x0, WS38x0) in the sensorsID section of your console or WS View Plus app or the WebUI in order to avoid wrong registrations. Do not leave the sensor ID entry in “learning” mode.

The learning mode is convenient at the initial start-up of your weather station, however, especially with Ecowitt compatible sensors and sensor arrays in your neighbourhood, it can also create unwanted results.

the phenomenon is often noticed in the Battery tile of your ecowitt.net dashboard (provided you have your console send its data to the Ecowitt Weather Cloud) where that sensor shows as offline.

For what sensor array names in the battery tile mean see sensor arry names in the Battery tile.

It can take a couple of days for the sensors to disappear from there as there is a grace period built into the ecowitt.net dashboard. The server there cannot know if the sensor in question is only temperarily not sending data (e.g. ran out of battery) or is permanently removed or was never one of the sensors you own.

————————————————————————————————————————————————————————————————-

wrong sensor sequence

if you have multiple sensors of the WN34, WN35, WH41/43, WH51, WH55 type (see ToC Sensors), the original sequence (channel number) may change after a reset, reboot or after power-cycling your console/gateway as the console will pick up the sensors in the sequence they transmit. Even though they should have the same transmission interval, the interval start can be different for each sensor and not always reflect the sequence you had them assigned earlier.

Therefore is is helpful to write down (or make a screencopy) of your sensors IDs and their assignment to multiple-sensor channels and then assign each sensor manually to re-establish the earlier sequence.

Also, (see above), deactivate/disable all sensors you do not have or don't want to be displayed on your console (you may have more than one console and may want to display different sets of your sensors on the different consoles).

A similar situation may occur when you have more than the maximum number of sensors of a type and have to spread them over two (or even more consoles). E.g. more than eight WH51 (Soil Moisture) sensors. We know about people who have up to 40 WH51 sensors spread over five GW1100 gateways.
————————————————————————————————————————————————————————————————-

cannot connect to the WebUI of my console/gateway

trying to connect to the WebUI of your gateway/console (e.g. GW2000) can provide the message URI (or URL) does not exist

This can happen after a reset, reboot, power-cycling or simply after some time period and is the result of a security feature. If one of the above activities (reboot etc.) happened, you can access the WebUI of the device only via your IP address only - no URI/URL e.g. 192.168.1.222/liveData.html


The WebUI rejects such requests and you have to start from the login page entering username (default: admin) and your password if you have set one. If not, leave the password field empty
————————————————————————————————————————————————————————————————-

cannot change the rain priority (traditional/piezo) in WS View Plus



changing the rain priority (making the choice which rain gauge to be displayed on a console with local network API) in WSV+ can be a bit tricky.

Tapping on the entry field doesn't seem to create any reaction from the app.

The trick is:
you have to tap in the very (right or left) corner of the “Rainfall data priotity” entry field for a little window to pop up where you can make your choice. 8-)

Don't forget to press “Save” (top right button) before leaving the page and wait for the little “Success” message in green letters to appear before you leave.
————————————————————————————————————————————————————————————————-

the yearly rain is not reset on January 1st at 00:00

  1. if you have a WS2910 console, you have to do it yourself manually every year
  2. for all other consoles/gateways you have to set the start of the rain season to January (usually under “Rain totals”). The console might be delivered with a different setting from the tests in quality assurance.


————————————————————————————————————————————————————————————————-

my outdoor array reads too high temperature

when exposed to direct solar irradiation, the small radiation shields of the WS69, WS80 or WS90 arrays may not have enough airflow and therefore will show higher temperature.

All consoles (except the WS2320 and WS2910) have a temperature compensation switch in either the console itself (HP25x0, HP350x) or in the WS View Plus app/WebUI which works with the T/RH sensors of the WH65/WS69/WS80/WS90 outdoor arrays.
Look for “device setting” and activate “temperature compensation”
WSV+: live data –> More –> Device settings
WebUI: Device Settings
see also passive radiation shields
————————————————————————————————————————————————————————————————-

cannot upgrade the firmware of my ultrasonic sensor array (WS80/WS85/WS90)

The upgrade procedure works with a Windows 7/10/11 computer. Meanwhile there is also the option to use Linux based computers. The descriptions are found in the upgrade packs for the respective upgrade.

the WS85 has it's own upgrade software (different chipset) - see WS85 firmware upgrade

You will need a USB data cable (!!) with a male micro-USB type A (or micro A) end piece to plug into the female USB outlet of the WS80/WS85/WS90 array. Not every USB cable you use for charging is a data cable. Charging cables often use only two wires for the electricity while data cables have to more wires connected (4 wires together) for the data exchange.
(do not confuse with a USB type C or a mini-USB type A (mini A), the latter is smaller and the end-piece is trapezoidal with clearly pronounced edges, micro-USB is still trapezoidal, bigger than the mini-USB and the edges are slightly rounded; the USB-C has no more edges)

Under Windows the DFU device (the WS80/WS90) will show only in the DfuSEDemo program interface after the data cable is connected and the WS80/WS90 is in reset mode. You have to press and hold the reset button > 5 seconds (WS80 needs an open paper clip end) until the blue LED shows a steady blue light. Then only the device becomes visible in the upgrade (“flash”) program and you can load the upgrade file as described in the upgrade instruction.

In principle it doesn't matter if the USB outlet you use at your computer is USB2 or USB3, but USB ports in general can be “moody” pieces and can be a nightmare. Sometimes you have to reboot your computer first to get them work electrically properly. Sometimes a simple restart/reboot is not enough (warm restart), but you need a full shutdown and a subsequent restart (cold restart) to get “the electricity” straight. Sometimes you have to change the USB port or even the computer before the connection gets properly established.

Finally, you have to verify if the installation of the upgrade program went well:
To do this, check whether the STMicroelectronics driver supplied with the upgrade software (STTub30.sys) is also located in the correct directories (copy manually from the ..\DriverStore to ..\System32 directory if necessary). After installation, DfuSeDemo.exe (the update programme - don't worry about the word demo 8-)) should be located in C:\Program Files (x86)\STMicroelectronics\Software\DfuSe v3.0.6\bin. The driver should be located under C:\Windows\System32\drivers\STTub30.sys and C:\Windows\System32\DriverStore\FileRepository\sttube.inf_amd64_a8b237bfe1fbdc78\x64\STTub30.sys.


————————————————————————————————————————————————————————————————-

I cannot switch on the WLAN ("WiFi") access point of my console/gateway

WLAN/WFI pairing prerequisites


————————————————————————————————————————————————————————————————-

my WH41 doesn't re-register or takes very long after a console reboot

the WH41 PM2.5 air quality outdoor sensors can be “moody” when re-registering after a reboot or power-cycling (which involves a reboot).

Due to the rather long transmission interval (once every 600 seconds/10 minutes), it can take up to ten minutes until the first signal after reboot is received by the console. And this doesn't mean that the signal could be properly processed. The console may discard the data package. Electromagnetic interference (EMI) or just an unfavourable location of either the console or the sensor may make this process take longer.

What can help to accelerate the process is to take off the rechargeable batteries from the WH41 for a few seconds (5-10) and then re-insert them. Then the first transmission will start once the sensor has booted up after a few seconds.

Also re-registering the sensor with its ID actively in the console can expedite the process (after having done the short-time battery removel).

When you have more than one WH41/WH43, disable them all in the console (sensors ID page) andremove the batteries from all. Then re-insert the battery for the WH41 you want to be on channel 1 and actively register it on the sensors ID page. Once done, go to the next sensor. Once the registration is initialized, you do not need to wait until the signal is received and processed and a “signal bar” appears. You can already continue.


————————————————————————————————————————————————————————————————-

my WH40 rain gauge doesn't connect to the console in spite of being in the direct view line

see WH40 no reception
————————————————————————————————————————————————————————————————-

Why is my rainfall data not displayed on my console screen ?

while for all consoles with the local Ecowitt network API both the traditional rainfall and the piezo rainfall can be displayed (in a table: WS View Plus, WebUI, on different tiles at the ecowitt.net dashboard), the display consoles can only show one type of rain (if they can display rain data at all [e.g. the WN182x consoles cannot]).

Here you have to select the rainfall type to be displayed - the key word is “rainfall data priority”. In the HP25x0 console you do it on the Setup –> More [Setup] page. For the consoles with the local Ecowitt network API you do it with either the WS View Plus app, the Ecowitt app or with the WebUI.
see a WebUI example below.
when you choose “piezoelectric rain gauge”, a WS85 or WS90 has to be registered in the console - otherwise only dashes (–.–) will be displayed
Don't forget to press “Save” !!!
By the way - piezoeletric calibration is only possible when rainfall priority “Piezoelectric rain gauge” has been chosen.

This does not apply to the WS2320 and WS2910 consoles as they can only receive data from the WH65/WS69 array.
————————————————————————————————————————————————————————————————-

my console doesn't start up anymore - only the message "Starting up ..." appears shortly in an endless cycle

this sometimes occurs with the WS2910, HP25x0 and HP350x consoles.
It is usually a sign of a faulty power supply. Replacing the power supply (the transformer piece) with a stable one will usually make the console work again.

my console/gateway keeps on restarting frequently
Something similar has been observed with the GW1x00, GW2000 gateways - not to say with all consoles in general.
Here it expresses as a frequent restart.
Again the root cause is often an unstable power adapter/power supply - may have grown unstable over time.
A replacement with a higher quality model often solves the issue.
————————————————————————————————————————————————————————————————-

when I try to configure my HP25x0/HP350x console with the Ecowitt app, the options are greyed out

only consoles with the local Ecowitt API can be configured with the WS View Plus app, the Ecowitt app or the WebUI (embedded webpage). The WS2320, WS2910, WS6006, HP25x0, HP350x console do not have that API. Only the weather service can be configured with the WS View Plus or Ecowitt app inside the local network.


————————————————————————————————————————————————————————————————-

my newly added sensor doesn't show on my console, app or on my ecowitt.net dashboard

when you newly added sensor doesn't show on either your console, the WS View Plus app or on your ecowitt.net dashboard (or on the Ecowitt app which also shows the dash board), then there are usually two possibilities:
1. the sensor is defective (unlikely but possible)
2. your firmware isn't upgraded to the latest verson which is able to handle that sensor (most cases)

This often happens with new products for which the console firmware wasn't programmed yet.
Depending on your console there can bee two types of firmware - for local processing and for sending/posting data to wether networks or a customer defined server separately or all in one firmware. see also: Firmware upgrade and version

If your firmware is not up-to-date, it may not be able to process and post your data properly and your data will be missing.

How to figure out your actual firmware version ?

  • in the device list of WS View Plus
  • on the 4 x settings (gear wheel) –> Factory –> About [Dsipaly] page for the HP25x0 / AMbient WS-2000/4000/5000 consoles
  • on the WebUI –> Device settings page of the conoles with local network API
  • on the WebUI of consoles with EasyWeatherPro WiFi firmware (section “version” or buttom right)


How to upgrade ? see link to “Firmware upgrade and version” above
————————————————————————————————————————————————————————————————-

the red LED of the outdoor sensor array (WH65/WS69/WS-2000-ARRAY) burns constantly and no data is reported

1. do a hardware reset of the array

2. (for DIY skilled people only ;-)) If the sensor array LED is solid on after battery change, it means the quartz oscillator is not working: the clock is not ticking.

What you can check: unsolder one of the capacitors that connects to one of the leads of the crystal, and it should help fixing this problem.


————————————————————————————————————————————————————————————————-

cannot connect a new sensor (array) to my GW1000

(or any other console/gateway)

based on the following scenario:

  • a WS80 array connected to a GW1000 fails and gets replaced
  • the new WS80 cannot be connected/registered to the GW1000 with WS View Plus
  • the old WS80 (faulty but some sensors still active) can be re-connected and shows live data
  • a factory reset of the GW1000 doesn't help - WSV+ keeps on showing an empty Live Data page, the more button doesn't respond
  • repetition of the pairing process doen't help

solution:

  1. start the pairing
  2. connect with smartphone to WLAN with SSID GW1000x-xxxx
  3. enter local WLAN SSID and router password and submit
  4. stop here !
  5. take a different device (PC, other mobile phone etc.) connected to the local (W)LAN to which the GW1000 was just paired
  6. enter http://192.168.4.1 into the URL field of a web browser - you will get a “not found” reply“ as the local network has a different subnet and the request is routed by the router to the internet where it won't be found
  7. now switch back with your smartphone still connected to GW1000a-WIFIxxxx to the local WLAN.
  8. the GW1000 will appear in the device list of WSV+ under the IP 192.168.4.1 (an IP address the GW1000 owns)
  9. the Live Data appear after tapping on the devie list entry and the SensorsID page can be reached and the new WS80 can be registered with its sensor ID


————————————————————————————————————————————————————————————————-

outdoor temperature/humidity no longer shown on the console display


the first thing to do is usually to reset the outdoor array via a software reset. and, if not successful, via a hardware reset. See how to reset an outdoor array.

if this doesn't help, see below:
the most observed reason for this symptom is a failure of the outdoor temperature/humidity (T/RH) sensor.
The T/RH sensor sits in inside the solar radiation shield (lowest portion of the array) - it is fixed with two long cross-head (Philips) screws which can be easily openened.
To verify you have to remove the T/RH sensor. In the newer WS80/WS80/WS69 arrays the sensor can be simply pulled out - and can be replaced by plugging in a replacement sensor, either SHT30 type or SHT35 type (see Accessories and Spare Parts). The latest models come with an extra protection against salty air.

Sometimes, especially when exposed to strong winds, vibrations from the pole can loosen the sensor. Just pull it out (recent models only) and put it back - it has a groove so you can only put it back one way. Then verify on the console or app or WebUI.

Only with very old WH65/WS69 and WS80 models there is a longer cable going upwards to a connector. With such older models more disassembly is necessary. Also for the old versions replacement T/RH sensor exist (see Accessories and Spare Parts).
After removing the T/RH sensor other data like solar data and UV data which might have disappeared at the same time will show again. The reason behind this behaviour is that the solar sensor and the T/RH sensor share the same data bus - hence one being defective can impact the other.
If the solar data do not reappear after removing the T/RH sensor, likely the solar sensor is defective (see next troubleshooting point).
————————————————————————————————————————————————————————————————-

solar data no longer shown on the console display


the first thing to do is usually to reset the outdoor array via a software reset. and, if not successful, via a hardware reset. See how to reset an outdoor array.

if this doesn't help, see below:

The missing display of solar data often goes along with a defective T/RH sensor (see defective T/RH sensor). When one disconnects the bigger cable between PCB and top and the T/RH reappears again, the solar sensor is defective. The top of a WS80/WS90 can be easily opened by turning the very top part anti-clockwise.



Reason for both sensors failing at the same time is that both sensors use the same data bus. Therefore, a defective solar sensor can also impact the data communication of the T/RH sensor.
For the WS80 and WS90 sensor arrays, replacement tops with solar panel and solar (light) sensors are available (see Accessories and Spare Parts)
————————————————————————————————————————————————————————————————-

my gateway console (Ecowitt GW1x00. GW2000, GW3000, Ambient ObserverIP1,2,3, AWN Weather Hub 2.0) gets stuck after some time of activity ...

several symptoms have been observed with the consoles and gateways either

  • showing data on their screen (consoles with display) or in the WS View Plus app or the WebUI but not in the Web
  • no more showing data on their screen or in the app or WebUI nor showing in the Web (WU, ecowitt.net, AWN, …)
  • showing data but no data arriving at the cloud service (WU, ecowitt.net, AWN, …)

these symptoms can be permanent or intermittently

there are in general several areas where things can go wrong:

  1. the gateway
  2. the local environment
  3. the local network
  4. the internet (access, connectivity, target server side)
  5. a data logger program like CumulusMX

WU is a special candidate - often the issue is at their end and looking up WU stations around you may show the same missing data as yours. This is often a local internet access issue but also issues at the WU server end. In such situations not much you can do except wait.
AWN (Ambient Weather Network) has introduced a further complication by forcing their users to connect to WU via AWN. As an Ambient user with a WS-2000/4000/5000 or WS-1965 or WS-2902 or WS-1938 console or an ObserverIP gateway ou can still do this directly by using the customized server option in each of these consoles. see FAQs “how do I post data to Wunderground with my Ambient console ?”

1. the gateway
a) general
As they say, shit happens, and sometimes 3rd party parts assembled to e.g. a GW2000 (like other pieces) can be faulty.
b) the lights/LEDs
There are several types of LEDs: blue + red (GW1x00, GW2000) or blue only (GW3000, WH2650, OberserverIP2, Weather Hub 2.0). Their meaning is usually described in the respective manuals.

Regarding the blue and red lights [GW1000, GW1100, GW1200, GW2000, where the red light may appear to be yellowish …) - blue is RF reception, red is (W)LAN connection. Depending on the number of sensors registered to your GW2000, the blue light may blink frequently - each successful reception of a sensor signal. The red light shows network activity, which, if posting to ecowitt.net, will be every minute only, if queried by data logging programs like CMX, weewx, Meteobridge etc. in the query interval.
with the blue only version you have to go with the model, RF reception always blinks, network activity may blink or be constant; fast blink (red or blue) is WLAN registration mode or Access point/hotspot active).


c) gateways with WLAN + LAN connectivity (GW2000, GW3000, Ambient ObserverIP2, AWN Weather Hub)
LAN connection is recommended - less potential disturbances - no special router registration procedure (WLAN provisioning, pairing) needed - just connect the gateway with a LAN cable with the router and the device is recognized.

even though in theory both interfaces (WLAN and LAN [Ethernet]) could be used in parallel, using only one of them reduces the possibilities of internal hick-ups. Where possible, the LAN connection is the more stable connection and also avoids disturbances by EMI (electromagnetic interference) created by household appliances, computers or even neighbourhood activities.

even though you can, if you are familiar with the procedure in your router, connect and assign a dynamically provided (via DHCP) IP address to the connected device (gateway, console) and make it quasi-static, we recommend making this address static inside the gateway network configuration. This avoids a lot of potential network issues also in situations where you have to exchange your router.

if you use the LAN port, we recommend to deactivate the WLAN interface inside the network settings of the gateway.


On the “Local Network page” of their WebUI choose
IP Address Mode static
Static IP Address xxx.xxx.xxx.xxx * (the IP address dynamically provided by the DHCP server of your router)
Static Subnet Mask 255.255.255.0 (unless you have a special network setup)
Static Gateway xxx.xxx.xxx.1 (assumption - local IP address of your internet router, last digit usually “1!)
Static DNS Server 208.67.220.220 (that's an open DNS server - you can of course choose your own)
Save - wait for “success” message.


*) on private networks, these address ranges are used (these ranges do not occur in the internet)

  • 192.168.0.1 - 192.168.255.255
  • 10.0.0.1 - 10.255.255.255
  • 172.16.0.1 - 172.31.255.255


The first thing to do if your gateway is “on strike” is a reset/reboot


There are two types of reset
a) restart/reboot using either the reset button or power-cycling the device (disconnect from power and reconnect).
b) factory reset: press and hold the reset button (see manual) for > 10 seconds. All configuration data will be lost. Therefore, if still possible, note down configuration data (calibration, rain totals) before the factory reset.

When it is connected via a LAN cable, it will receive its new (could also be the old one) IP address from the router - no pairing with app, WLAN etc. needed. Then it will be accessible via the WebUI http://IP-address.
(this does not apply to the vintage ObserverIP1 gateways and clone models - they have a special software tool [Windows based] for communication and configuration. See manual)

Now, with a factory reset done, LAN connection only, static IP address and the above DNS server, it may start behaving “wisely” again. Fingers crossed. If not, you'll have to wait for the new one.

2. the local environment

(EMI)

3. the local network

(WLAN access points, switches, router)

4. the internet access

(router, modem –> internet; DNS servers used, CDN (Content Delivery Network), target/remote server (ecowitt.net, wunderground, AWN), remote server local infrastructure

5. CumulusMX (CMX)


when using with the local http API, you have to make sure that the gateway MAC address entered in the CMX settings and the IP address entered match !!! CMX uses the MAC address of the gateway for the ecowitt.net backfill option together with an API and APP key. The MAC address is needed to identify together with the API and API key at ecowitt.net and to get access to the console data saved in the Ecowitt cloud.
If MAC and device IP don't match, CMX will still retrieve the data from the gateway with the entered IP address, but as a side-effect, the wrong MAC address will block the functioning of the WebUI, the WS View Plus app, the Customized Server posting and the regular posting to ecowitt.net


to be completed


———————————————————————————————————————————————————————————————-

after upgrade to the automatic sea level pressure calculation (SLP/REL) my REL pressure display is wrong, sometimes fluctuating

1. make sure you have entered the altitude (height above sea level resp. ground level elevation + height above ground) of your barometric sensor (console, WH32B/WN32P, new WS69) into the “REL altitude” calibration field (press three times the gear wheel button)

2. when your outdoor temperature sensor (outdoor array, WN32) is missing or not working, the algorithm for calculating the normalized sea level pressure cannot be applied as it needs the current outdoor temperature value.
———————————————————————————————————————————————————————————————-

console screen freezes (HP25x0 and WS-2000/4000/5000)

symptom:
the console display freezes - clock doesn't continue running …
only power-cycling brings it back - however, often not for a long time

possible solutions:
1. exchange the power supply to a stable edition
2. your SD card (if inserted) might be defective - remove it and power-cycle the console
(reformatting it may also solve the issue)
3. what sometimes helps is to clean the oscillator crytal on the console PCB (mainboard)
for this you have to open the console housing (Philips screws) with the display down - disconnect from power before 8-)
locate the oscillator crystal and clean it with isopropanol (alcohol) using cotton swabs (USA)/ cotton buds (UK)


———————————————————————————————————————————————————————————————-

rain data is not displayed on the console display

  1. you have a WS85 or WS90 haptic sensor array (piezo):
    • check on the SensorsID page of your console if the sensor is registered with a sensor ID
      with a WN1700, WN1980, WN182x, WS28x0, WS39x0 console you can also use
    • check under rain totals (for a HP25x0 console on the Setup –> More page) if you have set the rainfall priority to “piezo”
  2. you have a WN20, WH40 or WS69 rain gauge
    • check on the SensorsID page of your console if the sensor is registered with a sensor ID
      with a WN1700, WN1980, WN182x, WS28x0, WS39x0 console you can also use
    • check under rain totals (for a HP25x0 console on the Setup –> More page) if you have set the rainfall priority to “traditional”

the WebUI will show both types of rainfall when both types of rain gauges are registered at the same time
be aware that the sensor hierarchy (display priority) applies


———————————————————————————————————————————————————————————————-

new troubleshooting topic


———————————————————————————————————————————————————————————————-

faq2.txt · Last modified: by 127.0.0.1