WS5500 – technical overview & data ingest

On this page we show how we used the customized upload of the WS5500 console to receive weather data ourselves, analyse it, and ultimately integrate it into our own processing chain.

1. Starting point and goal

The Alecto WS5500 console allows you to send data not only to standard platforms (such as Ecowitt and Wunderground), but also through a separate upload to a custom endpoint of your own choosing. That sounds simple, but in practice the route turns out to be less straightforward than the manual suggests. In fact, the standard manual barely explains this option at all.

Our goal was not merely to get the data “somewhere online”, but specifically to:

• receive the raw upload ourselves;
• see the real POST format;
• log the data locally or in a controlled way;
• then process the data ourselves for database, cache, and website use.

2. Console configuration / customized upload

The key to your own data flow is the console’s Customized setting. That is where you define the destination address to which the console may post its data. These settings can only be configured through a separate app: WSView Plus (formerly WS View). That is confusing, because both apps can still be found in the app store.

Alecto states on its website that the old WS View app is no longer supported. Another important feature of WSView Plus is the ability to update the console firmware. As of 2026-04-12, the latest known version is EasyWeather V1.7.5.

3. Which app should you use?

The Alecto website states that the WS View app is no longer supported. In practice, WSView Plus works fine, but patience is required. It is not unusual to have to reopen the app after changing a setting. Combined with the short time the console keeps its Wi-Fi active, using it is, honestly speaking… a bit of a challenge.

4. Adding a device in the app

Open the app and press the plus button at the bottom center. Then choose your device from the list. Next, put the console into pairing mode by pressing and holding the WIND and PRESSURE buttons together for a moment. The Wi-Fi symbol in the top-left corner will then start flashing.

Now go to the Wi-Fi settings of your phone or tablet. In the list of available networks, your console should now offer a connection in the form EasyWeather-WIFIbbbb (the last four hex characters depend on your device). After selecting this network, you may get a warning about no internet or unsecured Wi-Fi; you can ignore that. Then return to the WSView Plus app.

5. Navigate to customized upload

For this section, we assume that you have successfully paired your device in the app. When you open the app, you will see the station listed there (and if you have paired multiple weather stations, you will of course see multiple entries). To change settings, the app must reconnect to the console over Wi-Fi. So: put the console back into Wi-Fi mode and reconnect to the station in your Wi-Fi settings.

Once that works — the green popup confirms the connection — you can click on the device. This opens the settings menu. There, go to the last tab: Customized.

In the screenshot below you can see my own settings. I send the data to a local server (NAS or raspberry_PI or ...). The IP address of that server is entered under Server IP / Hostname. Below that comes the Path where the data should land; in my case a PHP script in a web folder on my server. I also use Port 80 and an Upload Interval of 60 seconds. If you manage to save those settings before the console Wi-Fi shuts down again: congratulations, you now have a working customized upload.

Many people use Home Assistant as a receiving server. Unfortunately, I can't really help you further in that area; roughly speaking, it comes down to integrating the Ecowitt station into HA and "sending" the weather data to it. From there, you have to process the received POST data yourself.

6. What does the most basic POST look like?

At its core, the customized upload is surprisingly simple: an HTTP POST with content type application/x-www-form-urlencoded and a series of key/value pairs.

(The example above shows only part of the actual POST output.)

The console expects a simple HTTP endpoint here. So this is not JSON or a complex API call, but a classic form-style POST with key/value pairs.

6.1 Measurements and units

The WS5500 console reports its values in imperial units by default. For use in Europe, those values almost always need to be converted to metric.

6.2 Short conversions (imperial ↔ metric)

7. Limitations and practical issues

On paper, customized upload looks like little more than “enter a URL and you are done”. In practice, however, we ran into several limitations.

7.1 Empty User-Agent

One of the most striking points was that the console POST did not include a normal User-Agent. That may seem minor, but many hosting environments, firewalls, or WAF rules treat an empty User-Agent as suspicious or unwanted traffic.

Solution: see section 8.

7.2 HTTP / HTTPS issues

A second practical issue is that customized upload does not always play nicely with a modern hosting environment that relies heavily on HTTPS, redirects, and security rules.

Solution: see section 8.

7.3 Lack of transparent documentation

It took quite a bit of searching to find out how the console actually behaves in practice. Scattered manuals, forums, and derivative brand documentation each provide fragments, but not one complete technical picture of the chain.

Solution: this web page.

8. Why use an intermediate step via NAS (Now Raspberry Pi)?

Precisely because of the combination of limited upload options, an empty User-Agent, and possible HTTPS/WAF issues, we chose to use an intermediate layer in the form of a NAS (now Raspberry Pi).

• first receive the data locally and in a controlled way;
• log raw payloads and headers;
• add our own validation and error handling;
• build a clean follow-up POST ourselves;
• forward to production through a route that is easier to control.

With such a setup, the console does not become a full-blown “internet client”, but rather a simple supplier of raw data to an intermediate layer you control yourself.

8.1 Additional advantage: security and flexibility

An additional advantage of the intermediate step is the way in which the data is sent toward the internet.

In our setup, the console sends its data only to a local receiver (NAS or Raspberry Pi). From that intermediate layer, a new POST is then built and sent to an external destination, such as our hosting provider.

As a result, the intermediate processor only needs to allow outgoing traffic to the internet. There is therefore no need for a direct connection from the “big bad internet” into the local network.

A second advantage is flexibility: from the intermediate processor you can easily send the payload to multiple destinations at the same time.

The console itself supports only one customized upload, but your intermediate layer can, for example, send the same data to:

• your own website;
• your own Home Assistant;
• a database or API;
• a second test environment or logging endpoint.

That turns the console into a simple data supplier, while real control remains entirely in your own infrastructure.

Why the NAS ''first'', and now the Raspberry Pi? My old NAS used 25 watts of power but WAS IMMEDIATELY available for the development phase. So that NAS has now been phased out. The 'Pi' was still gathering dust in the attic, but uses much less power for the same result. So the Raspberry Pi has since been dusted off and is the receiving and sending point. The NAS is sort of retired. I'm keeping it on hand as a hardware fallback 😆.

9. Playing with the data

If you want to experiment with the received data yourself, you do not immediately need to build a complete processing chain, database, or dashboard. Sometimes it is enough to first look at what the console is actually sending.

The idea is deliberately kept KISS:

• place the index.php in a web folder or subfolder on, for example, a Raspberry Pi, NAS, or local PC;
• fill in the correct values in the console under Customized for Server IP / Hostname, Path, Port, and Upload Interval;
• then open the URL in your browser;
• as soon as the console posts data, you immediately see what arrives.

So this is not a final solution, but it is a very useful first step: first verify that the chain works, and only then continue building.

10. Documentation and downloads

The documents below are relevant to this page. Some are hosted locally on this site; in addition, one original manual is available from an external source. All links open in a new browser tab.

• ws5500_basic_receiver_en.zip — ultra simple test receiver (EN) with index.php and English readme
• WS5500_manual_EN.pdf — 2953 Kb → English manual, station setup
• WS-5500_PDS_COMP.pdf — 995 Kb → product data sheet, what the PWS can do
• WS5500_hesdo_com.pdf — 2659 Kb → explanation of console linking to Wunderground
• Original multi-language manual — 65 Mb ! → remote download location