Tempest Weather System

[havnegata]

Anyone know if this one is possible to get working with Domoticz other than IFTTT? Looks https://weatherflow.com/tempest-weather-system/

[EdwinK]

Too bad, shipping to the US only

[Toulon7559]

Be optimistic!
Latest planning info:
presently shipping to USA and Canada, end of August to rest of the world.

[havnegata]

US shipping is not a problem. You can use services as Jetcarrier and circumvent shipping challenges:-) Problem is to get it working with Domoticz...

[Toulon7559]

Getting the data from Tempest probably is not really a problem.
The predecessor is Weatherflow and they apply the same infrastructural setup.
Meanwhile 'sniffers' in development & operation which look at the internet-interface of this system and extract the data from/by the message-stream.

[waaren]

US shipping is not a problem. You can use services as Jetcarrier and circumvent shipping challenges:-) Problem is to get it working with Domoticz...

Tempest is responding to a API call in JSON so it is not very difficult to get the data to display in domoticz sensors. Can be done via
dzVents, classic Lua, Python, Nodered, Dashticz, Bash, and probably a bunch of other programs.

check this example

[havnegata]

Thanks,that is good information!

[Toulon7559]

Got the Tempest running quite quick by means of their App.
Standard, most immediate way to obtain info-display is through the remote weatherflow-server:
=> dedicated webpages for the user and for public display.

To get the data to Domoticz several routes available of different layout and trajectory:
- Weatherflow has a standard facility to upload data to a WUnderground-account, and Domoticz has standard interface to download from a WUnderground-account. 'More of same' as present for other Meteo-Systems towards Domoticz, probably not utilizing all features available in Tempest.
Goal achieved, although a long route, but simplest for setup.
- UDP is the most direct&local from the system's hub as per https://weatherflow.github.io/Tempest/api/udp/v143/
Requires catching the single messages in the datastream, and from their contents need compilation of Virtual Devices etc..
- 'Compromis' seems JSON-file as summary from the Weatherflow-server, as indicated by waaren
Options for JSON-extraction described in more detail at https://weatherflow.github.io/Tempest/api/ incl. the required generation of API-key/access-token.

Have not seen a realised solution for the latter 2 setups [would be nice to have one such realisation as script or plugin for Domoticz]

[Toulon7559]

Further searching for practical solutions without reinventing the wheel ....

Free IFTTT-capability with Tempest weather system applets is a subscription service with a limited free tier,
according to https://tempest.weatherflow.com/beginne ... -home-tech

Reading from Weatherflow's remote server is the basic configuration for free, wider access to the info:
calling a JSON-file from their server therefore an obvious plan.

Local tapping of the datastream from the Hub provides highest independence for reading Tempest's info.
Requires sniffing the UDP-messages coming from Tempest's Hub.
Weatherflow already operates for some time, therefore probably the question has already been raised & solved:
is a related UDP-Sniffer-software available, either 'sucking' all messages, or extracting selected messages?
Software like Wireshark obviously can do the sniffing, but linked, online subsequent data-extraction is a functional requirement to avoid a multiple-step-process: that calls for another construction.

Addition on 30th of November, 2020
It seems that the Weatherflow server internally makes a statistical/auto-calibration correction to various values:
not sure that corrections are fed back to the sensor-station (at least in the API-description no sign of any message(s) realising that function).
Considering the effort to get 'calibrated output', then the JSON-file from the Weatherflow server (or the WU-link) may be the first/easy choice, because incl. the corrections/calibrations.
From another forum was informed that in this area differences exist between messages for Weatherflow_AIR/SKY and for Tempest:
have to be careful which solution is valid.

[Toulon7559]

As indicated in previous message, the path over Weatherflow's server and subsequently over WUnderground provides for Domoticz the 'basic' set of meteodevices.
To check the possibilities of directly tapping Weatherflow's server, below is a Python-script to call for TEMPEST the JSON-file from that Weatherflow-server, to extract data from the JSON-file and to upload to Virtual Devices in Domoticz.
It is a variation of a script earlier published in this forum.
To demonstrate the principle for just a few more values from Tempest than the 'basic' values mentioned above extracted from WU.
Obviously the script can be extended to cover all present 29 values from the JSON-file (as 'big' replacement for the WU-extraction), but then it seems as clean-up advisable to apply a recursive approach for data-extraction, instead of simple repetition of the structure as for the shown 3 values.
The 29 'outdoor_keys' may be a useful element to steer the recursive script over the series 'obs' [0] next in the JSON-file.

Subsequent recombination & compilation of the data into Virtual Devices is also an interesting puzzle:
some combinations are obvious as per API/JSON_Domoticz, perhaps in combination with the Extra API for Python-programmers
Some other values are 'new' and may need rethinking for a meaningful, new combined Virtual Device, such as the 3 values for lightning possibly feeding 1 related widget. In this script already a preposition for a legal upload to Domoticz for such combination.

Code: Select all

#!/usr/bin/python
# -*- coding = utf-8 to enable reading by simple editors -*-
# (c)2020 script compiled by Toulon7559 from various material from forums
# Version 00_201206, reading JSON, setting Virtual Devices in Domoticz
# 
# For JSON-extraction required to have Station_ID [= number of 5 digits] and AccessToken
# as per https://weatherflow.github.io/Tempest/api/
# --------------------------------------------------
# Line009 = PREPARATION & SETTING
# --------------------------------------------------
# Imports for script-operation
import json
import urllib
print ('Start of script Tempest00')
# --------------------------------------------------
# Line016 = EXTRACT CONTENTs BY JSON-CALL to the Weatherflow_Server
# --------------------------------------------------
# General call-string = https://swd.weatherflow.com/swd/rest/observations/station/[your_station_id]?token=[your_access_token]
# Below fill-in is for illustration with fake id+token!
page = urllib.urlopen('https://swd.weatherflow.com/swd/rest/observations/station/12345?token=a1b2c3d4e5f6g7h8i9')
content_test = page.read()
obj_test = json.loads(content_test)
print(obj_test)
# --------------------------------------------------
# Line025 = Extraction & Setting of components
# --------------------------------------------------
BRIGHT = obj_test['obs'][0]['brightness']
PRESST = obj_test['obs'][0]['pressure_trend']
BLITZ0 = obj_test['obs'][0]['lightning_strike_count']
BLITZ1 = obj_test['obs'][0]['lightning_strike_count_last_1hr']
BLITZ3 = obj_test['obs'][0]['lightning_strike_count_last_3hr']
# -------------------------------------------------
# Line032 = Upload to Virtual Devices at Domoticz1
# -------------------------------------------------
# JSON-calls for update:
# Destination device type = Lux => /json.htm?type=command&param=udevice&idx=IDX&svalue=VALUE  with VALUE = value of luminosity in Lux (INTEGER/FLOAT)
# Destination device type = Text => /json.htm?type=command&param=udevice&idx=IDX&nvalue=0&svalue=TEXT   with TEXT = Text you want to display
# Destination device type = Custom => /json.htm?type=command&param=udevice&idx=IDX&nvalue=0&svalue=VALUE
#domoticz settings
domoticz1_host      	= '127.0.0.1' # for local host
domoticz1_port      	= '8080'
domoticz1_url       	= 'json.htm'
domoticz1_idx1          = '77' #idx of new device Lux, for Brightness
domoticz1_idx2          = '78' #idx of new device Text, for Pressure_trend
domoticz1_idx3          = '79' #idx of new device Custom, for Lightning_Strike_Count
# -------------------------------------------------
# Line046 = UPLOAD to local Domoticz1
# -------------------------------------------------
url = ("http://" + domoticz1_host + ":" + domoticz1_port + "/" + domoticz1_url+ "?type=command&param=udevice&idx=" + domoticz1_idx1 + "&nvalue=0&svalue=" + str(BRIGHT))
urllib.urlopen(url)
url = ("http://" + domoticz1_host + ":" + domoticz1_port + "/" + domoticz1_url+ "?type=command&param=udevice&idx=" + domoticz1_idx2 + "&nvalue=0&svalue=" + str(PRESST))
urllib.urlopen(url)
url = ("http://" + domoticz1_host + ":" + domoticz1_port + "/" + domoticz1_url+ "?type=command&param=udevice&idx=" + domoticz1_idx3 + "&nvalue=0&svalue=" + str(BLITZ0) + ";" + str(BLITZ1) + ";" +str(BLITZ3))
urllib.urlopen(url)
# -------------------------------------------------
# Line057 = End of script
)

Practical hint:
The IP-address set in line 038 is for operation inside the local host [= machine running this script].
Perhaps very obvious for many people:
if you intend to upload to Domoticz at a remote IP-address, take care that the destination IP-address is within the same (W)LAN-segment as the machine running this script.
Otherwise, you might be wondering why the upload does not arrive at destination ..............

[Toulon7559]

As described in previous messages, in the Tempest-PWS the UDP-messages contain the raw measured values from the sensors.
A setup which is functionally not much different from the older weather-sensorsystems, where raw data from the sensors along local paths goes to software in processing and/or in Console for further application, with correction due to calibration performed in that processing and/or in the Console.

Therefore also for Tempest still useful and not exotic to make a sniffer for the UDP-messages, with an attached converter to convenient message-format, parallel to the dataflow to & through the Weatherflow-server:
such DIY-flow provides local autonomy for application at choice of Tempest-information.

As expected, the very active weewx-community already has solutions at hand to extract the data from the UDP-messages:
the software package at https://github.com/captain-coredump/weatherflow-udp is a driver for weewx, with the weewx main-package providing full PWS-functionality.
Perhaps even more compatible with Domoticz
https://community.weatherflow.com/t/wea ... ility/2053

Everything Python, for either setup just a Domoticz-enthousiast required to make the translation to the business-end towards Domoticz' Virtual Devices.

[Toulon7559]

If you want to have a solution really quick for display through a Raspberry of the info from a Weatherflow PWS,
look at https://community.weatherflow.com/t/wea ... nsole/1933

Weatherflow_piconsole

Weatherflow_piconsole.jpg (11.81 KiB) Viewed 5910 times

This software applies the output of the Weatherflow-Server.

[Toulon7559]

Fitting twice the same capability, but slightly different, is often asking for trouble.

Therefore the following question:
just checking before starting,
because better safe than sorry .....

The core of the package https://github.com/vinceskahan/weatherflow-udp-listener is Listen.py, the sniffer.
Extension part of the package is fitting software for the interface to paho-mqtt and to influxdb

Installation

This requires installing the paho mqtt and influxdb python libraries.
On a debian(ish) system that can be done by:

# for python3

Code: Select all

sudo apt-get install -y python3-pip && sudo pip3 install paho-mqtt influxdb

# for python2

Code: Select all

sudo apt-get install -y python-pip  && sudo pip  install paho-mqtt influxdb

Can such extra mqtt safely be fitted besides the 'normal' MQTT as set through 'Setup/Hardware' for handling of other dataflows, such as for ESP8266 and TTN?
Same question in fact for influxdb?

[Toulon7559]

An effectively working frontend is the start for reading of the UDP-messages.
Besides WeeWX-drivers also simpler, general 'listener'-solutions available:
see https://github.com/p-doyle/Simple-Weath ... n-Listener
This example Python-script catches the single UDP-messages, resulting in printing of the dictionaries of the 'major data-set/obs' and several specific data-sets.
The contents and interval for 'major data-set/obs' are basis for basic meteo-read-out, while the other data-sets add specific, actual information for 'rapid wind', 'start-of-rain-event', 'lightning-event' and 'status/QC of sensor & hub'.

With this approach, next step in the direction of Domoticz (or any other application) is extraction&translation of contents from the data-sets and linking to the application.

Addition 11April2021.
In my configuration I use json-files and xml-files for general/common distribution of sensor-data to applications.
Therefore aiming to tweak the original Listener-script to act as nodal point to generate JSON-files for the periodic 'major data set/obs', high-rate 'rapidwind', 'start-of-rain-event' and 'lightning-event'.
Also output of an XML-file for 'major data set/obs'.
For the configuration this script will be the local source of Tempest_sensordata, comparable to the other sensors.
Tweaking-aspects:
1) inserted the hints from Peter Doyle to limit the mapping to just labels, without units
[You still can read in the script which units are applicable for the labels&values]
2) marked with # those scriptlines becoming redundant/ not functional
3) inserted for each segment the scriptlines for generation of the json-files
4) inserted the scriptlines for generation of the xml-file for the obs-set
5) changed some mapping for shorter labels, because dicttoxml 'simplifies' the translation if label-text is too long, and that causes key-problems for later handling
6) commented out the scriptline for DateTime, because in first stage a most actual timing is not yet essential.
With reduced mapping the original scriptline causes error => on ToDo-list to find a solution for that function with mapping-without-units.
7) generation-functions included for json-files for 'start-of-rain-event' and for 'lightning-event'.
Script runs without errors, but those generation functions need applicable weather for real testing, because event-driven.
On ToDo-list is addition of generation of related xml-files, after the json-generation is OK.
8) added some 'cosmetics' in the form of header and a highest level line-count

At the receiving end, the distribution and extraction of info from the json-files or xml-file can be realised in the various ways described in this forum for driving virtual devices in Domoticz etc.
In most cases rather simple extraction from the fields of values relative to keys, except time which is epoch/utc-format and needs translation if 'normal' layout for date&time is required.

Be aware, that all data in these json-files and xml-file are raw sensor-data!
Also the xml-output segment needs update: see addition of 26th August 2022 in this message
For a correct functional implementation of the data for meteo-applications, in the application you need to perform calibration & correction relative to sensors known to be OK!!
[Conceptually it would be better if such correction was included 'at the source' in this script]

Code: Select all

#!/usr/bin/python3
# -*- coding = utf-8 to enable reading by simple editors -*-
# Reading UDP messages from Tempest_sensor and generating JSON-File & XML-File.
# Original script by p-doyle is at https://github.com/p-doyle/Simple-WeatherFlow-Python-Listener
# This adaptation only tested with python3.7. XML-generation requires install of dicttoxml for python3.
# --------------------------------------------------
# Line 006 = PREPARATION & SETTINGs
# --------------------------------------------------
# Imports for script-operation

import socket
import select
import time
import struct
import pprint
import json
import datetime
import dicttoxml

# create broadcast listener socket
def create_broadcast_listener_socket(broadcast_ip, broadcast_port):

    b_sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
    b_sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)

    b_sock.bind(('', broadcast_port))

    mreq = struct.pack("4sl", socket.inet_aton(broadcast_ip), socket.INADDR_ANY)
    b_sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq)

    return b_sock

# map for the 'obs_st' type observations
OBS_ST_MAP = [
    ('Time Epoch', 'Seconds'),
#    ('Wind Lull (minimum 3 second sample)', 'm/s'),
#    ('Wind Avg (average over report interval)', 'm/s'),
#    ('Wind Gust (maximum 3 second sample)', 'm/s'),
    ('Wind Lull', 'm/s'),
    ('Wind Avg', 'm/s'),
    ('Wind Gust', 'm/s'),
    ('Wind Direction', 'degrees'),
    ('Wind Sample Interval', 'seconds'),
    ('Station Pressure', 'mb'),
    ('Air Temperature', 'C'),
    ('Relative Humidity', '%'),
    ('Illuminance', 'Lux'),
    ('UV', 'Index'),
    ('Solar Radiation', 'W/m^2'),
    ('Precip Accumulated', 'mm'),
    ('Precipitation Type', '0 = none, 1 = rain, 2 = hail'),
#    ('Lightning Strike Avg Distance', 'km'),
    ('Lightning Strike Distance', 'km'),
    ('Lightning Strike Count', ''),
    ('Battery', 'Volts'),
    ('Report Interval', 'Minutes')
]

# map for the 'rapid_wind' type observations
RAPID_WIND_MAP = [
    ('Time Epoch', 'Seconds'),
    ('Wind Speed', 'm/s'),
    ('Wind Direction', 'Degrees')
]

# map for the 'evt_strike' type observations
EVT_STRIKE_MAP = [
    ('Time Epoch', 'Seconds'),
    ('Distance', 'km'),
    ('Energy', '')
]

# ip/port to listen to
BROADCAST_IP = '239.255.255.250'
BROADCAST_PORT = 50222

# create the listener socket
sock_list = [create_broadcast_listener_socket(BROADCAST_IP, BROADCAST_PORT)]

# --------------------------------------------------
# Line 080 = SCRIPT EXECUTION
# --------------------------------------------------

while True:
    # small sleep otherwise this will loop too fast between messages and eat a lot of CPU
    time.sleep(0.01)

    # wait until there is a message to read
    readable, writable, exceptional = select.select(sock_list, [], sock_list, 0)

    # for each socket with a message
    for s in readable:
        data, addr = s.recvfrom(4096)

        # convert data to json
        data_json = json.loads(data)
 
        if data_json['type'] == 'obs_st':
            # takes the map list and the list of observations and creates a dictionary with the first value in
            # the map as the key and the first value in the list of observations as the value, second value
            # to second value, etc
# Original scriptline for full map conversion to dictionary:
#            observations = dict(zip(OBS_ST_MAP, data_json['obs'][0]))
            # For edit of the OBS_ST_MAP variable to just be strings and get rid of the units:
            string_map = [key[0] for key in OBS_ST_MAP]
            observations = dict(zip(string_map , data_json['obs'][0]))
# If you want to keep the units you could concatenate them together with:
#            string_map = [key + " - " + units for key, units in OBS_ST_MAP]
# Original scriptline for correct fill of datetime in original setup incl. units:
#            observations['Datetime'] = datetime.datetime.fromtimestamp(observations[('Time Epoch', 'Seconds')])

            # Insert dictionary into JSON-file
            with open('/home/pi/Tempest_Sensor.json', 'w') as outfile:
                json.dump(observations, outfile)

            # Convert dictionary to XML-file & print
            TempestObs_xml = dicttoxml.dicttoxml(observations, attr_type=False)
            print(TempestObs_xml)
            TempestObs_xml = str(TempestObs_xml)
            xml_output = open("/home/pi/Tempest_Sensor.xml",'w')
            xml_output.write(TempestObs_xml)
            xml_output.close()
            print ('List of Obs-values')
            pprint.pprint(observations)    

        elif data_json['type'] == 'rapid_wind':
# Original scriptlines:
#            observations = dict(zip(RAPID_WIND_MAP, data_json['ob']))
#            observations['Datetime'] = datetime.datetime.fromtimestamp(observations[('Time Epoch', 'Seconds')])
            # For edit of the RAPID_WIND_MAP variable to just be strings and get rid of the units:
            string_map = [key[0] for key in RAPID_WIND_MAP]
            observations = dict(zip(string_map , data_json['ob']))
            # Insert dictionary into JSON-file
            with open('/home/pi/Tempest_RWind.json', 'w') as outfile:
                json.dump(observations, outfile)

            print ('RapidWind')
            pprint.pprint(observations)

        elif data_json['type'] == 'evt_strike':
# Original scriptlines:
#            observations = dict(zip(EVT_STRIKE_MAP, data_json['evt']))
#            observations['Datetime'] = datetime.datetime.fromtimestamp(observations[('Time Epoch', 'Seconds')])
            # For edit of the EVT_STRIKE_MAP variable to just be strings and get rid of the units:
            string_map = [key[0] for key in EVT_STRIKE_MAP]
            observations = dict(zip(string_map , data_json['evt'][0]))
            # Insert dictionary into JSON-file
            with open('/home/pi/Tempest_SInfo.json', 'w') as outfile:
                json.dump(observations, outfile)

            print ('StrikeInfo')
            pprint.pprint(observations)

        elif data_json['type'] == 'evt_precip':
            # no other information other than the timestamp is included so just print a simple message
            print ('StartOfRain')
            print('It started raining at {}!'.format(datetime.datetime.fromtimestamp(data_json['evt'][0])))
            # Insert StartOfRain into JSON-file
            SORTime = format(datetime.datetime.fromtimestamp(data_json['evt'][0]))
            with open('/home/pi/Tempest_SORain.json', 'w') as outfile:
                json.dump(SORTime, outfile)

        else:
            print('OtherInfo')
            print(data_json)
            
        print

[Toulon7559]

When json-files and xml-file(s) have been created, after upload the next stage is finding compatible readers which can dissect those files for applications, such as the driving of virtual devices in Domoticz or feeding RRDTools for making graphs.
While testing those reader-setups you find how 'compatible' the layout of the json-files and xml-files is.
Developments obviously continue, and the following text is a temporary description, hoping to speed up corrections with your hints.

Reading & Decoding XML-files
For file-generation and reader-setup using constructions elsewhere operating without any problem.
Surprise that the generated xml-file now has 2 extra characters (b') at the start and 1 extra character (') at the end

Code: Select all

b'<?xml version="1.0" encoding="UTF-8" ?><root><Time_Epoch>1618391739</Time_Epoch><Wind_Lull>0.0</Wind_Lull><Wind_Avg>0.0</Wind_Avg><Wind_Gust>0.0</Wind_Gust><Wind_Direction>0</Wind_Direction><Wind_Sample_Interval>3</Wind_Sample_Interval><Station_Pressure>1032.16</Station_Pressure><Air_Temperature>6.59</Air_Temperature><Relative_Humidity>64.78</Relative_Humidity><Illuminance>72422</Illuminance><UV>4.39</UV><Solar_Radiation>604</Solar_Radiation><Precip_Accumulated>0.0</Precip_Accumulated><Precipitation_Type>0</Precipitation_Type><Lightning_Strike_Distance>0</Lightning_Strike_Distance><Lightning_Strike_Count>0</Lightning_Strike_Count><Battery>2.714</Battery><Report_Interval>1</Report_Interval></root>'

When manually removed, a manually triggered dissect by the reader is OK, but those extra characters are hurdles for easy, automatic processing .......
No clear reason in the Listener-script in previous message why these 3 characters appear.
'Simple' question:
1) how to automatically suppress or remove those 3 extra characters during or after the file-generation?
Python3.x-script is preferred.
Added 26th August 2022: see this message

Reading & decoding JSON-files
For the json-files something similar with the Python-script attached in the spoiler at the end of this message:
- local reading of the files coming out of the Listener-script is OK, =directly called from the folder /home/pi by urllib (under Python2.x)
- if reading those exactly same files from another IP-address at the LAN or from 'more remote' URL, then the error report in the spoiler immediately below that no json object can be found [and therefore the alternative scriptlines for remote reading 'commented/disabled'].
Apparently something wrong in the url-string.

Spoiler: show

Traceback (most recent call last):
obj_test1 = json.loads(content_test1)
File "/usr/lib/python2.7/json/__init__.py", line 339, in loads
return _default_decoder.decode(s)
File "/usr/lib/python2.7/json/decoder.py", line 364, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python2.7/json/decoder.py", line 382, in raw_decode
raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded

When trying Python3.x for the json-reader, then with the present script complaints that urllib is not Python3.x
Anyway with Python2.x so far that all data can be extracted from the json-file.
=> Pragmatically a solution is available, but questions to be solved:
2) what is hindering the 'remote' reading?
3) how to adapt for reading with Python3.x?

Compile for upload to Virtual Devices in Domoticz
After reading & decode the next hurdle is compilation of update-commandlines for new, related virtual devices in Domoticz.
Custom Sensor for each value is creation of a high number of devices:
as alternative the application of the combined devices as defined for Domoticz seems a solution.
But not all required filling-data is available.
Filling BAR_FOR is simplest, because it can be set to 0 = 'No info'. WD requires a simple repeating construction.
WindTemp can be defaulted to some value. WindChill requires a calculation.
But how a simple Pythonic solution for realistic filling of HUM_STAT and RAINRATE?
Pending a solution for those aspects, the related values have been defaulted.
The script below runs OK if manually triggered from Putty's CLI, or as part of a cronjob (with attributes set to 755).
4) Somebody seeing possibilities to squeeze the long list of script-lines for upload to the virtual devices?

Spoiler: show

#!/usr/bin/python
# -*- coding = utf-8 to enable reading by simple editors -*-
# (c)2021 script compiled by Toulon7559 from various material from forums, version 01_210516
# --------------------------------------------------
# Line005 = PREPARATION & SETTING
# --------------------------------------------------
# Imports for script-operation
import json
import urllib # with this import the script will run under python2.x, NOT under python3.x!!!

# --------------------------------------------------
# Line012 = EXTRACT CONTENTs BY JSON-CALLs
# --------------------------------------------------
# Python-script weatherflow_listener.py generates file Tempest_Sensor.json
# which is local source file for general meteo-info out of UDPTempest
page = urllib.urlopen('/home/pi/Tempest_Sensor.json') # reading from local folder
# page = urllib.urlopen('http://127.0.0.1:8080/home/pi/Tempest_Sensor.json')
# page = urllib.urlopen('http://192.168.1.7:8080/home/pi/Tempest_Sensor.json')
content_test = page.read()
obj_test1 = json.loads(content_test)
# Tempest_RWind.json is source file for Rapid Wind info [= high rate info]
page = urllib.urlopen('/home/pi/Tempest_RWind.json') # reading from local folder
content_test = page.read()
obj_test2 = json.loads(content_test)
# Tempest_SORain.json is source file for Start-Of-Rain Event info
page = urllib.urlopen('/home/pi/Tempest_SORain.json')
content_test = page.read()
obj_test3 = json.loads(content_test)
# Tempest_SInfo.json is source file for Lightning_Strike Event info
# page = urllib.urlopen('/home/pi/Tempest_SInfo.json')
# content_test = page.read()
# obj_test4 = json.loads(content_test)

# --------------------------------------------------
# Line035 = SURVEY for compilation for virtual devices
# --------------------------------------------------
# Extraction is aimed at subsequent recompilation for JSON-calls for update of virtual devices in Domoticz.
# As reference for inventory the general layouts of applicable json-strings acc. to API/JSON Domoticz:
# THB = /json.htm?type=command&param=udevice&idx=IDX&nvalue=0&svalue=TEMP;HUM;HUM_STAT;BAR;BAR_FOR -- Type THB
# with HUM_STAT = Humidity status: 0 = Normal, 1 = Comfortable, 2 = Dry, 3 = Wet
# with BAR_FOR = Barometer forecast: 0 = No info, 1 = Sunny, 2 = Partly cloudy, 3 = Cloudy, 4 = Rain
# Wind = /json.htm?type=command&param=udevice&idx=IDX&nvalue=0&svalue=WB;WD;10WS;10WG;WTemp;WChill -- Type Wind, WD is text as subset from catalogue NWES
# Rain = /json.htm?type=command&param=udevice&idx=IDX&nvalue=0&svalue=100RAINRATE_Hour;RAINCOUNTER -- Type Rain
# RainType = /json.htm?type=command&param=udevice&idx=IDX&nvalue=0&svalue=VALUE -- Type Custom Sensor with 1 numeric value, or inserted in Rain as rainrate
# Light = /json.htm?type=command&param=udevice&idx=IDX&svalue=VALUE -- Type Lux
# UVI = /json.htm?type=command&param=udevice&idx=IDX&nvalue=0&svalue=UV;TEMP -- Type UVI, Temp must be 0 for compatibility
# SolarRad = /json.htm?type=command&param=udevice&idx=IDX&nvalue=0&svalue=VALUE -- Type Solar Radiation
# LightningD = /json.htm?type=command&param=udevice&idx=IDX&nvalue=0&svalue=VALUE -- Type Custom Sensor with 1 numeric value [Distance]
# LightningC = /json.htm?type=command&param=udevice&idx=IDX&nvalue=0&svalue=VALUE -- Type Custom Sensor with 1 numeric value [Count]
# SOR_Event = /json.htm?type=command&param=udevice&idx=IDX&nvalue=0&svalue=VALUE -- Type Custom Sensor with 1 value [Time of event]
# LS_Event = /json.htm?type=command&param=udevice&idx=IDX&nvalue=0&svalue=VALUE;VALUE1;VALUE2 -- Type Custom Sensor with 3 values [Time of event, Distance, Energy]

# --------------------------------------------------
# Line054 = EXTRACTION of DATA & scaling of values
# --------------------------------------------------
print(obj_test1) # Contents of original UDP-package Observations
print
epoch = obj_test1['Time Epoch']
print('epoch = ',epoch)
was = obj_test1['Wind Avg']
print('was = ',was)
ws10 = was * 10 # scaling for virtual device
wgs = obj_test1['Wind Gust']
print('wgs = ',wgs)
wg10 = wgs * 10 # scaling for virtual device
wb = obj_test1['Wind Direction']
print('wb = ',wb)
# Line068 = Translation of wb into wd
# wd is result of translation of numeric value to wind_direction_text
wd = "NW" # placeholder for testing
if wb >= 11.25 and wb < 33.75:
wd = "NNO";
elif wb >= 33.75 and wb < 56.25:
wd = "NO";
elif wb >= 56.25 and wb < 78.75:
wd = "ONO";
elif wb >= 78.75 and wb < 101.25:
wd = "O";
elif wb >= 101.25 and wb < 123.75:
wd = "OZO";
elif wb >= 123.75 and wb < 146.25:
wd = "ZO";
elif wb >= 146.25 and wb < 168.75:
wd = "ZZO";
elif wb >= 168.75 and wb < 191.25:
wd = "Z";
elif wb >= 191.25 and wb < 213.75:
wd = "ZZW";
elif wb >= 213.75 and wb < 236.25:
wd = "ZW";
elif wb >= 236.25 and wb < 258.75:
wd = "WZW";
elif wb >= 258.75 and wb < 281.25:
wd = "W";
elif wb >= 281.25 and wb < 303.75:
wd = "WNW";
elif wb >= 303.75 and wb < 326.25:
wd = "NW";
elif wb >= 326.25 and wb < 348.75:
wd = "NNW";
else:
wd = "N";

print('wd = ',wd)
# Line105 = Air pressure
spa = obj_test1['Station Pressure'] # spa = "Station Pressure Absolute"
# correction required for calibration & translation to MSL-value
relpress = 1
biaspress = 0
spa = spa * relpress + biaspress # Correction for calibration
print('spa = ',spa)
station_altitude = 17 # pressure_sensor is at +17 m relative to MSL => MSL-pressure is higher than station pressure
bar = spa + (station_altitude/8.5) # correction of Station_Pressure into MSL_pressure
print('bar = ',bar)
bar_for = 0 # default to 'Stable'
print('bar_for = ',bar_for)
# Line = Temperatures
temp = obj_test1['Air Temperature'] # to be corrected for calibration
reltemp = 1
biastemp = 0
temp = temp * reltemp + biastemp # correction of air temperature for calibration
print('temp = ',temp)
wtemp = 22 # default for testing, alternative: windtemp = airtemp?
wchill = 24 # default for testing, calculation to be added. For high temperatures fill-in by heat-index?
# Line125 = Humidity
rhum = obj_test1['Relative Humidity'] # to be corrected for calibration
relhum = 1
biashum = 0
rhum = rhum * relhum + biashum # Correction of humidity for calibration
print('rhum = ',rhum)
hum_stat = 0 # default to 'No Info'
print('hum_stat = ',hum_stat)
# Line133 = Rain
raintoday = obj_test1['Precip Accumulated']
print('raintoday = ',raintoday)
rtype = obj_test1['Precipitation Type']
print('rtype = ',rtype)
rtype100 = rtype * 100 # scaling taking place of rainrate in virtual rain-device
# Line139 = Light & UV
light = obj_test1['Illuminance']
print('light = ',light)
solrad = obj_test1['Solar Radiation']
print('solrad = ',solrad)
uvi = obj_test1['UV']
print('uvi = ',uvi)
uvt = 0 # Temp must be 0, unless UV-sensor is type TFA3
# Line147 = LightningStrikes
ls_distance = obj_test1['Lightning Strike Distance']
print('lsdistance = ',ls_distance)
ls_count = obj_test1['Lightning Strike Count']
print('lscount = ',ls_count)
print('End of Observations')

# Line154 = RapidWind
print(obj_test2) # Contents of original UDP-message RapidWind
print('Reservation for Rapid Wind')
RWTime = obj_test2['Time Epoch']; print(RWTime)
RWDirection = obj_test2['Wind Direction']; print(RWDirection)
RWSpeed = obj_test2['Wind Speed']; print(RWSpeed)
print('End of RapidWind')

# Line162 = StartOfRainEvent
print(obj_test3) # Contents of original UDP-message Start-Of-Rain-Event
print('Reservation for SOR_Event')
SORTime = obj_test3; print(SORTime)
print('End of SOR_Event')

#Line168 = LightningStrikeEvent
# print(obj_test4) # Contents of original UDP-message Lightning-Strike-Event
print('Reservation for LS_Event')
# LSTime = obj_test4['Time Epoch']; print(LSTime)
# LSDistance = obj_test4['Distance']; print(LSDistance)
# LSEnergy = obj_test4['Energy']; print(LSEnergy)
print('End of LS_Event')

# -------------------------------------------------
# Line177 = SETTINGS FOR UPLOAD at Domoticz3
# -------------------------------------------------
# Define the ip, port, base-url, idx & type of your virtual sensors
domoticz3_host = '127.0.0.1' # local host
domoticz3_port = '8080'
domoticz3_url = 'json.htm'
domoticz3_idx1 = '27' #idx of new device THB
domoticz3_idx2 = '28' #idx of new device Wind
domoticz3_idx3 = '29' #idx of new device Rain
domoticz3_idx4 = '30' #idx of new device Lux
domoticz3_idx5 = '31' #idx of new device UVI
domoticz3_idx6 = '32' #idx of new device SolarRad
domoticz3_idx7 = '33' #idx of new device Custom for LightningD
domoticz3_idx8 = '34' #idx of new device Custom for LightningC
# domoticz3_idx9 = Raintype #idx of new device Text for Rain_type
# domoticz3_idx10 = SORain #idx of new device Text for Start-Of_Rain event
# domoticz3_idx11 = LSInfo #idx of new device Text for Lightning_Strike event

# -------------------------------------------------
# Line196 = URLs for ACTUAL UPLOAD to Domoticz3
# -------------------------------------------------
#
# THB = /json.htm?type=command&param=udevice&idx=IDX&nvalue=0&svalue=TEMP;HUM;HUM_STAT;BAR;BAR_FOR -- Type THB
url = ("http://" + domoticz3_host + ":" + domoticz3_port + "/" + domoticz3_url+ "?type=command&param=udevice&idx=" + domoticz3_idx1 + "&svalue=" + str(temp) + ";" + str(rhum) + ";" + str(hum_stat) + ";" + str(bar) + ";" + str(bar_for))
urllib.urlopen(url)
# Line 202
# Wind = /json.htm?type=command&param=udevice&idx=IDX&nvalue=0&svalue=WB;WD;10WS;10WG;WTemp;WChill -- Type Wind
url = ("http://" + domoticz3_host + ":" + domoticz3_port + "/" + domoticz3_url+ "?type=command&param=udevice&idx=" + domoticz3_idx2 + "&nvalue=0&svalue=" + str(wb) + ";" + str(wd) + ";" + str(ws10) + ";" + str(wg10) + ";" + str(wtemp) + ";" + str(wchill))
urllib.urlopen(url)
# Line 206
# Rain = /json.htm?type=command&param=udevice&idx=IDX&nvalue=0&svalue=100RAINRATE_Hour;RAINCOUNTER -- Type Rain
url = ("http://" + domoticz3_host + ":" + domoticz3_port + "/" + domoticz3_url+ "?type=command&param=udevice&idx=" + domoticz3_idx3 + "&nvalue=0&svalue=" + str(rtype100) + ";" + str(raintoday))
urllib.urlopen(url)
# Line 210
# Light = /json.htm?type=command&param=udevice&idx=IDX&svalue=VALUE -- Type Lux
url = ("http://" + domoticz3_host + ":" + domoticz3_port + "/" + domoticz3_url+ "?type=command&param=udevice&idx=" + domoticz3_idx4 + "&svalue=" + str(light))
urllib.urlopen(url)
# Line 214
# UVI = /json.htm?type=command&param=udevice&idx=IDX&nvalue=0&svalue=UV;TEMP -- Type UVI, Temp must be 0
url = ("http://" + domoticz3_host + ":" + domoticz3_port + "/" + domoticz3_url+ "?type=command&param=udevice&idx=" + domoticz3_idx5 + "&nvalue=0&svalue=" + str(uvi) + ";" + str(uvt))
urllib.urlopen(url)
# Line 218
# SolarRad = /json.htm?type=command&param=udevice&idx=IDX&nvalue=0&svalue=VALUE -- Type Solar Radiation
url = ("http://" + domoticz3_host + ":" + domoticz3_port + "/" + domoticz3_url+ "?type=command&param=udevice&idx=" + domoticz3_idx6 + "&nvalue=0&svalue=" + str(solrad))
urllib.urlopen(url)
# Line 222
# LightningD = /json.htm?type=command&param=udevice&idx=IDX&nvalue=0&svalue=VALUE -- Type Custom Sensor with 1 numeric value [Distance]
url = ("http://" + domoticz3_host + ":" + domoticz3_port + "/" + domoticz3_url+ "?type=command&param=udevice&idx=" + domoticz3_idx7 + "&svalue=" + str(ls_distance))
urllib.urlopen(url)
# Line 226
# LightningC = /json.htm?type=command&param=udevice&idx=IDX&nvalue=0&svalue=VALUE -- Type Custom Sensor with 1 numeric value [Count]
url = ("http://" + domoticz3_host + ":" + domoticz3_port + "/" + domoticz3_url+ "?type=command&param=udevice&idx=" + domoticz3_idx8 + "&nvalue=0&svalue=" + str(ls_count))
urllib.urlopen(url)

# -------------------------------------------------
# Line232 = End of script
# -------------------------------------------------
print ('End of script')

Addition Feb10,2022:
Following scriptlines might be used as basis to calculate wchill.
Borrowed from StackOverflow, in the subject thread with various versions, with this one [using 2*For-loop] checking that inputs for temperature & wind are within range of validity for windchill.

Spoiler: show

for temp in range(-35,15,5):
# print 'temperature is %d' % temp
for wind in range(0,85,5):
wchill = 13.12 + (.6215 * temp) - (11.37 * wind ** 770.16) + (.3965 * temp * wind **0.16)
# print 'wind is %d calculated wind chill is: %d' % (wind, wchill)

However, that checking of range in practise causes problems at the upper temperature limit, and therefore an 'unlimited' implementation further down that contribution in StackOverflow yields better results (after minding the scaling from m/s to kmh!), better explained under this weblink.
The following scriptlines already tuned&tested for the script in the previous message.

Spoiler: show

import math
# wind = float(input("Enter wind speed in kilometers/hour: ")) but Domoticz handles speed as m/s => scaling required 1m/s = 3.6 kmh
was_wc = 3.6 * was
# temperature = float(input("Enter air temperature in degrees Celsius: "))
wchill = 13.12 + 0.6215*temp - 11.37*math.pow(was_wc , 0.16) + 0.3965*temp*math.pow(was_wc , 0.16)
print('wchill = ',wchill)

[Toulon7559]

The basis for converting the UDP-messages through JSON-files into Domoticz-devices now is available.
Perhaps time to translate into a plugin for Domoticz (on the way correcting the aspects mentioned in the previous message)?
For that exercise help is appreciated from somebody having experience with building a plugin.
Instead of a plugin (obviously) also a functionally similar dzVents-script would be a pragmatic solution.

[Toulon7559]

'Universal' aid for calculation of derived meteo-values like Dewpoint, WindChill, HeatIndex and ApparentTemperature is offered by Python-module Meteocalc, incl. handling of either metric or anglosaxion/imperial scaling for inputs.

[Toulon7559]

Sometimes it takes time until hitting applicable information.

Solution for question 1) in this message probably given in this information from Stackoverflow.
=> Reason for the 3 extra characters in the XML-output: wrong setup for coding of the XML-string.

But wondering why the 'problem' does not occur in the predecessor-scripts:
headscratching related to 'subtleties' in Python-application ........

[windsphere]

An effectively working frontend is the start for reading of the UDP-messages.
_______________________________________

Many thanks for posting, very helpful!

I was wondering if the Tempest API supports a more rapid polling of the wind sensor data?
And if anyone has a working python implementation of this?

From what I've been able to gather, the Tempest internally pre-averages the wind samples and provides the average (of however many internal samples it is), to the UDP stream roughly every 3 seconds. Assuming this is correct, a high wind gust could easily be averaged to something much lower, and effectively missed.

For anyone who knows the inner workings of the Tempest API, is there a way to directly poll -just the wind speed value- on-demand at a rate of at least once per second ? (2 or 3 per second preferred)

Thanks in advance

[Toulon7559]

As far as known, the UDP-stream from the Tempest-hub is the fastest dataflow in the chain between sensor and Weatherflow-server,
and did not (yet) see an entry to manipulate the speed of that dataflow.