This binding enables acting as a receiver of updates from devices that post measurements to <https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php>.
If the hostname is configurable - as on weather stations based on the Fine Offset Electronics WH2600-IP - this is simple, otherwise you have to set up dns such that it resolves the above hostname to your server, without preventing the server from resolving the proper ip if you want to forward the request.
The server thus listens at `http(s)://<your-openHAB-server>:<openHAB-port>/weatherstation/updateweatherstation.php` and the device needs to be pointed at this address.
If you can't configure the device itself to submit to an alternate hostname you would need to set up a dns server that resolves rtupdate.wunderground.com to the IP-address of your server and provide it as the DHCP dns-server to the device.
Make sure not to use this dns server instance for any other DHCP clients.
The request is in itself simple to parse, so by redirecting it to your openHAB server you can intercept the values and use them to control items in your home.
E.g. use measured wind-speed to close an awning or turn on the sprinkler system after some time without rain.
This binding allows you to mix and match products from various manufacturers that otherwise have a closed system.
If you wish to pass the measurements on to rtupdate.wunderground.com, you can use a simple rule that triggers on the `wundergroundupdatereceiver:wundergroundUpdateReceiver:<channel-id>:metadata#last-query-trigger` to do so.
It can also be used to submit the same measurements to multiple weather services via multiple rules.
## Supported Things
Any device that sends weather measurement updates to the wunderground.com update URLs is supported.
It is easiest to use with devices that have a configurable target address, but can be made to work with any internet-connected device, that gets its dns server via DHCP or where the DNS server can be set.
## Discovery
The binding starts listening at the above-mentioned URI as soon as it is initialized.
Any request with an unregistered stationId is recorded and if auto-discovery is enabled appears in the inbox, otherwise can be registered when a manual scan is initiated.
For each request parameter a channel is generated, based on a list of known parameters from <https://support.weather.com/s/article/PWS-Upload-Protocol?language=en_US> and other observed parameters from various devices.
If you have a device that submits a parameter that is unknown in the current version of the binding please feel free to submit an issue to have it added.
While discovery is active, either in the background or during a manual scan, any request parameters that don't have a channel associated with them are added to the thing's channels.
This supports using multiple devices that submit measurements to the same station ID.
The thing is the wunderground account, not the individual devices submitting measurements.
## Thing Configuration
The only configurable value is the station id, which should match the one configured on the device.
If you don't plan on submitting measurements to wunderground.com, it can be any unique non-empty string value, otherwise it must be the actual station ID.
## Channels
Each measurement type the wunderground.com update service accepts has a channel.
The channels must be named exactly as the request parameter they receive.
I.e. the wind speed channel must be named `windspeedmph` as that is the request parameter name defined by Wunderground in their API.
| windgustdir | wind-gust-direction | Number:Angle | Gust Direction | Current wind gust direction expressed as an angle using software specific time period. | Wind |
| tempf | temperature | Number:Temperature | Outdoor Temperature | Current outdoor temperature | Temperature |
| dateutc-datetime | dateutc-datetime | state | Last Updated as DateTime | The date and time of the last update in UTC as submitted by the device converted to a DateTime value. In case of 'now', the current time is used. | Metadata |
| last-received-datetime | DateTime | state | Last Received | The date and time of the last update. | Metadata |
The PASSWORD, action and realtime parameters are ignored, as they are wunderground technical constants, that devices must send.
The ID parameter is used to identify the correct thing the request pertains to, i.e. the stationId configuration value.
As described by the wunderground specification a device can submit multiple values for the outdoor temperature, soil temperature, soil moisture and leaf wetness channels by inserting an index number into the name of the request parameter, fx. tempf can be temp1f, temp2f, etc.
This is supported by the discovery mechanism, creating a channel for each of the values.
Configuration using thing and item files is not the recommended method, as you have to manually replicate the configuration discovery produces.
Channels _must_ be named as the request parameters in the channel type table, otherwise the binding will not be able to update with values from requests.
So the request parameter names submitted by your particular device(s) need to be found before being able to write appropriate thing files.
You need to intercept a request from your devices(s) using something like wireshark.
Both thing and item files must be created manually to produce a result practically identical to the one produced through automatic discovery.
Assuming you have intercepted a request such as `https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php?ID=MYSTATIONID&PASSWORD=XXXXXX&windspeedmph=3.11&dateutc=2021-02-07%2014:04:03&softwaretype=WH2600%20V2.2.8&action=updateraw&realtime=1&rtfreq=5`, you can configure a thing to intercept the request thus:
The binding tries to post received values as the item types described in the channel types table, so attaching a channel that takes a given type to an item of a different type has undefined behaviour.
