public/openhab-addons
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

[wundergroundupdatereceiver] Bugfixes: Regenerate trigger channel with proper type and more metadata. Normalize channel names. It might be easiest to delete and allow recreation of channels. (#13327)

Browse Source 
* [wundergroundupdatereceiver] LAST_QUERY parameter should not be mapped automatically
* [wundergroundupdatereceiver] All channeltype props need to be applied
Especially the channel kind
* [wundergroundupdatereceiver] Remove illegal characters from channel name

Additionally expand the channel naming test to assert the generated channelUID and test that _ in names isn't inadvertently replaced

* [wundergroundupdatereceiver] Don't default AutoUpdatePolicy on creation
* [wundergroundupdatereceiver] Migrate changed channel to trigger type

Signed-off-by: Daniel Demus <daniel-github@demus.dk>
This commit is contained in:
Daniel Demus
2022-12-01 22:47:11 +01:00
committed by GitHub
parent 9cc3cd0cf9
commit 43d01ad49c
9 changed files with 241 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
bundles/org.openhab.binding.wundergroundupdatereceiver/README.md
View File

@@ -6,7 +6,7 @@ This binding enables acting as a receiver of updates from devices that post meas
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 as dns to the device does DHCP.
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.
@@ -19,6 +19,7 @@ It can also be used to submit the same measurements to multiple weather services
## Supported Things
Any device that sends weather measurement updates to the wunderground.com update URLs is supported.
Multiple devices submitting to the same wunderground account ID can be aggregated.
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
@@ -42,7 +43,9 @@ If you don't plan on submitting measurements to wunderground.com, it can be any
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.
The channel name set up in the binding should be considered an id with no semantic content other than pointing to the wounderground API.
Illegal channel id characters are converted to -.
For example, AqPM2.5 has a channel named `AqPM2-5`.
The channel name set up in the binding should be considered an id with no semantic content other than pointing to the wunderground API.
Additionally there is a receipt timestamp and a trigger channel.
### Request parameters are mapped to one of the following channel-types: