Meteobridge is a most flexibele device to act as a nodal point for collection of weatherdata and output/upload to various organisations.
Although plenty of options already included, sometimes connections missing, usually because the interface between Meteobridge and the other device not existing.
Having a collection of weathersensors not compatible with Meteobridge, but interfacing to Domoticz,
now looking for an online interface from Domoticz to Meteobridge, aiming for ‘best of 2 worlds’:
- data collection & preparation by Domoticz
- merger/integration & translation by Meteobridge for further upload.
Emulation in Domoticz of one of the 'real' weatherstations in the list seems a bit overdone.
Thinking about application of the available weatherstation-option in Meteobridge for either ‘Ecowitt protocol’ or ‘userdefined’.
'Ecowitt protocol' is popular for transfer of data for the FOSHK/Ecowitt sensors, already touching Domoticz, because RFLink Gateway is compatible for reading FOSHK/Ecowitt-sensors into Domoticz, but probably elaborate to implement for the other direction = interfacing from Domoticz, cloning/emulating FOSHK/Ecowitt-sensoroutput. [Furthermore such emulation might be conflicting if already 'real' FOSHK-sensors in the configuration]
Less elaborate or less risky, under the cover of 'userdefined', this CS-plugin is an interesting one, because it's data-package contains all elements for a weatherstation.
Interface for only one T&H-sensor in this DL-plugin with a completely different (but not easy) approach for getting the info inside Meteobridge.
The plugin to read the data from the local Luftdaten-setup is also interesting, because already reading a JSON-format and very compact.
For all 3 plugins also interesting to see the application of awk for shorthand-scripting.
The question is how to compatibly prepare&provide the required data at/from the Domoticz-side.
Any usable examples in Domoticz?
Upload from Domoticz to Meteobridge
Moderator: leecollings
-
Toulon7559
- Posts: 848
- Joined: Sunday 23 February 2014 17:56
- Target OS: Raspberry Pi / ODroid
- Domoticz version: mixed
- Location: Hengelo(Ov)/NL
- Contact:
Upload from Domoticz to Meteobridge
Last edited by Toulon7559 on Thursday 08 February 2024 15:48, edited 2 times in total.
Set1 = RPI-Zero+RFXCom433+S0PCM+Shield for BMP180/DS18B20/RS485+DDS238-1ZNs
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
-
Toulon7559
- Posts: 848
- Joined: Sunday 23 February 2014 17:56
- Target OS: Raspberry Pi / ODroid
- Domoticz version: mixed
- Location: Hengelo(Ov)/NL
- Contact:
Re: Upload from Domoticz to Meteobridge
The simplest way to get hold of data from a Virtual Device in Domoticz is to call JSON-output per device by and then (for each desired device) have the MB-plugin extracting required info from the presented, big JSON-file per Virtual Device.
However, easier for an MB_plugin if Domoticz collects the info and generates a compact JSON-file in a layout (nearly) compatible with an adapted, existing MB_plugin.
Have been 'fiddling' with the MB_plugin for reading a local Luftdaten-setup with SDS011.
Made a static JSON-file mimicking such local Luftdaten_JSON-file, but then with contents as from 2 Virtual Devices for Temp&Humidity:
see file MB_WS7000P12_2TH.json in the zip-file.
Tested with success, means that static basis is OK.
Making a dynamic version of that JSON-file is different story.
Use Python-scripting for that exercise.
Reading the Vitual Devices is not a big deal, as well as extraction of selected values.
Next step is re-compilation towards a JSON-file for the MB-plugin with dynamically updated values.
The script-segment below shows the scriptlines being tested.
2 Approaches included for the re-compilation:
- Approach1 in lines 292 till 302 applies a dictionary as starting-point to generate a 'Luftdaten-like' JSON-file,
and at same time also an equivalent XML-file (for any other application)
- Approach2 in lines 302 till 308 is simpler, more brute force, string-generation towards file-generationApproach1 is OK for dynamic update of values for the outer keys of the nested dictionary, but the script fails when the values must be updated for the inner keys.
If commented like shown, the script runs without error report for this segment: see file MB_WS7000P12_test1.json in the zip-file.
However useless, because no update of values for the inner keys, which unfortunately contain the sensor-data.
The 'problem' is handling of the boundary-markers [ and ] around the section with inner keys.
Tried several approaches as found by Googling for update of value-strings for inner keys,
but apparently yet missing the appropriate implementation in lines 289 ~291
Also tried 'split in 2 segments for outer keys and inner keys' & 'update of values'& 'rebuild' of the dictionary, for rebuild using mapping like this and comparable description:
update of the split segments is OK, but subsequent rebuild is failing, again for handling of those boundary-markers [ and ].
Approach2 is so far OK that it generates a JSON-file with correctly updated values in the whole file, but with ' as delimiters:
see file MB_WS7000P12_test2.json in the zip-file.
However, that is not compatible with the MB-plugin under test.
Changing the MB-plugin to deal with ' instead of " as delimiters not yet successful.
Neither success to modify the scripting for JSON-file generation in this script to get " as delimiters.
Tried various approaches for global replace in a file, but did not find a working function as solution in line 308.
Various functions OK for a replace of string with letter(s) and/or number(s),
but not working for replace of only single character ' to be changed into single character ", due to problems with correct use of quotes in the definitions.
Because each character has an ASCII-number, have also looked for a replace-function applying that charateristic, but not yet with positive result.
Question:
somebody knowing a working solution for completion of one or for both approaches?
Code: Select all
http://<ip-adress-of-raspberry>:8080/json.htm?type=devices&rid=<device-number>However, easier for an MB_plugin if Domoticz collects the info and generates a compact JSON-file in a layout (nearly) compatible with an adapted, existing MB_plugin.
Have been 'fiddling' with the MB_plugin for reading a local Luftdaten-setup with SDS011.
Made a static JSON-file mimicking such local Luftdaten_JSON-file, but then with contents as from 2 Virtual Devices for Temp&Humidity:
see file MB_WS7000P12_2TH.json in the zip-file.
Tested with success, means that static basis is OK.
Making a dynamic version of that JSON-file is different story.
Use Python-scripting for that exercise.
Reading the Vitual Devices is not a big deal, as well as extraction of selected values.
Next step is re-compilation towards a JSON-file for the MB-plugin with dynamically updated values.
The script-segment below shows the scriptlines being tested.
2 Approaches included for the re-compilation:
- Approach1 in lines 292 till 302 applies a dictionary as starting-point to generate a 'Luftdaten-like' JSON-file,
and at same time also an equivalent XML-file (for any other application)
- Approach2 in lines 302 till 308 is simpler, more brute force, string-generation towards file-generation
- Spoiler: show
Code: Select all
# --------------------------------------------------
# Line 269 = Compile specific datafile as data source for Meteobridge-Plugin
# --------------------------------------------------
# This datafile in structure mimicks a datafile as coming from a Luftdaten-setup:
# tuned layout is implemented by means of the layout of the dictionary.
import json
import dicttoxml
dattim = datetime.now().strftime('%Y%m%d %H:%M')
time = datetime.now().strftime('%H:%M:%S')
utcdate = datetime.utcnow().strftime('%d%m%Y')
utctime = datetime.utcnow().strftime('%H:%M:%S')
System_epoch = utc_to_epoch(now_utc); print(System_epoch) # System epoch
AGE3 = round((System_epoch - (TIM1_epoch + TIM2_epoch)/2), 0); print (AGE3) # data staleness
# Line 281 = Setup of default dictionary [see remark in previous, equivalent section]
MB_WS7000P12_dict1 = {"utcdate":"30-01-2024","time":"22:12:51","age":"11","timestamp":"22:12:51","sensordatavalues":[{"value_type":"humid150","value":"91.00"},{"value_type":"temp150","value":"6.50"},{"value_type":"dew150","value":"6.50"},{"value_type":"humid010","value":"91.00"},{"value_type":"temp010","value":"6.50"},{"value_type":"dew010","value":"6.50"}]}
# Line 284 = Link values of dictionary to values in script
MB_WS7000P12_dict1["utcdate"] = utcdate
MB_WS7000P12_dict1["time"] = time
MB_WS7000P12_dict1["age"] = AGE3
MB_WS7000P12_dict1["timestamp"] = TIMSTMP2
# MB_WS7000P12_dict1["sensordatavalues"]["value_type":"temp150","value"] = TEMP1
# MB_WS7000P12_dict1["sensordatavalues"]["value_type":"humid150","value"] = HUM1
# MB_WS7000P12_dict1["sensordatavalues"]["value_type":"dew150","value"] = DEW1
# MB_WS7000P12_dict1["sensordatavalues"]["value_type":"temp010","value"] = TEMP2
# MB_WS7000P12_dict1["sensordatavalues"]["value_type":"humid010","value"] = HUM2
# MB_WS7000P12_dict1["sensordatavalues"]["value_type":"dew010","value"] = DEW2
# Line 292 = Make JSON-file
with open('MB_WS7000P12_test1.json', 'w') as outfile:
json.dump(MB_WS7000P12_dict1, outfile)
# Line 295 = Convert the updated dictionary to XML-file & print
MB_WS7000P12_xml = dicttoxml.dicttoxml(MB_WS7000P12_dict1, attr_type=False)
print(MB_WS7000P12_xml)
xml_output = open("MB_WS7000P12_status.xml",'w')
xml_output.write(str(MB_WS7000P12_xml))
xml_output.close()
If commented like shown, the script runs without error report for this segment: see file MB_WS7000P12_test1.json in the zip-file.
However useless, because no update of values for the inner keys, which unfortunately contain the sensor-data.
The 'problem' is handling of the boundary-markers [ and ] around the section with inner keys.
Tried several approaches as found by Googling for update of value-strings for inner keys,
but apparently yet missing the appropriate implementation in lines 289 ~291
Also tried 'split in 2 segments for outer keys and inner keys' & 'update of values'& 'rebuild' of the dictionary, for rebuild using mapping like this and comparable description:
update of the split segments is OK, but subsequent rebuild is failing, again for handling of those boundary-markers [ and ].
Code: Select all
Line 302 = Alternative method to make input-string and compilation
Compilation = open('MB_WS7000P12_test2.json','w') # output of selected values to file
Compilation.write("{'utcdate':'" + str(utcdate) + "','utctime':'" + str(utctime) + "','age':'" + str(AGE3) + "','timestamp':'" + str(TIMSTMP1) + "','sensordatavalues':[{'value_type':'humid150','value':'" + str(HUM1) + "'},{'value_type':'temp150','value':'" + str(TEMP1) + "'},{'value_type':'dew150','value':'" + str(DEW1) + "'},{'value_type':'humid010','value':'" + str(HUM2) + "'},{'value_type':'temp010','value':'" + str(TEMP2) + "'},{'value_type':'dew010','value':'" + str(DEW2) + "'}]}\n")
Compilation.close()
# Line 307 = Global replace character ' by character "
# global_replace (MB_WS7000P12_test2.json, MB_WS7000P12_output2.json,''','"')
see file MB_WS7000P12_test2.json in the zip-file.
However, that is not compatible with the MB-plugin under test.
Changing the MB-plugin to deal with ' instead of " as delimiters not yet successful.
Neither success to modify the scripting for JSON-file generation in this script to get " as delimiters.
Tried various approaches for global replace in a file, but did not find a working function as solution in line 308.
Various functions OK for a replace of string with letter(s) and/or number(s),
but not working for replace of only single character ' to be changed into single character ", due to problems with correct use of quotes in the definitions.
Because each character has an ASCII-number, have also looked for a replace-function applying that charateristic, but not yet with positive result.
Question:
somebody knowing a working solution for completion of one or for both approaches?
Last edited by Toulon7559 on Thursday 15 February 2024 10:47, edited 9 times in total.
Set1 = RPI-Zero+RFXCom433+S0PCM+Shield for BMP180/DS18B20/RS485+DDS238-1ZNs
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
-
Toulon7559
- Posts: 848
- Joined: Sunday 23 February 2014 17:56
- Target OS: Raspberry Pi / ODroid
- Domoticz version: mixed
- Location: Hengelo(Ov)/NL
- Contact:
Re: Upload from Domoticz to Meteobridge
Because it is not an obligation to stay with the Luftdaten-format for the JSON-file for the Meteobridge-Plugin,
the simpler solution probably might be the development of an adapted plugin for Meteobridge,
operating in conjunction with a JSON-file from Domoticz without those 'problematic' boundary-markers [ and ].
Perhaps even better to apply a dictionary which only has one key-layer,
not a level differentiation of segments with outer keys and inner keys.
With basic structure for all keys like the outer keys of the Luftdaten-dictionary.
To be continued in this thread.
Nevertheless, for other scripts and for general knowledge of Python-application the questions in the previous message are 'challenging':
who knows practical answers?
Especially resolution of the issue of global single-character replacement ‘ <> “ has value for file-manipulation.
the simpler solution probably might be the development of an adapted plugin for Meteobridge,
operating in conjunction with a JSON-file from Domoticz without those 'problematic' boundary-markers [ and ].
Perhaps even better to apply a dictionary which only has one key-layer,
not a level differentiation of segments with outer keys and inner keys.
With basic structure for all keys like the outer keys of the Luftdaten-dictionary.
To be continued in this thread.
Nevertheless, for other scripts and for general knowledge of Python-application the questions in the previous message are 'challenging':
who knows practical answers?
Especially resolution of the issue of global single-character replacement ‘ <> “ has value for file-manipulation.
Set1 = RPI-Zero+RFXCom433+S0PCM+Shield for BMP180/DS18B20/RS485+DDS238-1ZNs
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
-
Toulon7559
- Posts: 848
- Joined: Sunday 23 February 2014 17:56
- Target OS: Raspberry Pi / ODroid
- Domoticz version: mixed
- Location: Hengelo(Ov)/NL
- Contact:
Re: Upload from Domoticz to Meteobridge
The application of Meteobridge's Luftdaten-plugin as basis for a new Domoticz_PWS-plugin stuck on aspects as mentioned in previous messages.
Their CampbellSci-plugin proved easier starting point.
The mixing of the 2 plugins resulted in even easier plugin-package.
The adapted plugin meanwhile under test in my Meteobridge, as reported in the Meteobridge-forum.
A related Python-script for the Domoticz-side is below,
- to extract required sensordata from Domoticz and
- to recompile & upload that data in a file compatible with the plugin in Meteobridge.
The script is programmed with small steps,
not combining repeating similar functions, and
with plenty of supporting lines for comments, line-numbers and printlines.
You need to tune the script to which sensors of your PWS-configuration you want to send to Meteobridge,
what webspace you want to apply for file-transfer, and to your taste.
In that perspective surely expert-users might siginificantly squeeze the size of this script without loss of functionality.
As stated in the script-header, this script is on purpose running under Python2.x, because then a proven FTP-uploadfunction could be included:
for Python3.x and/or SFTP another solution required for that section.
Their CampbellSci-plugin proved easier starting point.
The mixing of the 2 plugins resulted in even easier plugin-package.
The adapted plugin meanwhile under test in my Meteobridge, as reported in the Meteobridge-forum.
A related Python-script for the Domoticz-side is below,
- to extract required sensordata from Domoticz and
- to recompile & upload that data in a file compatible with the plugin in Meteobridge.
The script is programmed with small steps,
not combining repeating similar functions, and
with plenty of supporting lines for comments, line-numbers and printlines.
You need to tune the script to which sensors of your PWS-configuration you want to send to Meteobridge,
what webspace you want to apply for file-transfer, and to your taste.
In that perspective surely expert-users might siginificantly squeeze the size of this script without loss of functionality.
As stated in the script-header, this script is on purpose running under Python2.x, because then a proven FTP-uploadfunction could be included:
for Python3.x and/or SFTP another solution required for that section.
- Spoiler: show
Set1 = RPI-Zero+RFXCom433+S0PCM+Shield for BMP180/DS18B20/RS485+DDS238-1ZNs
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Set2 = RPI-3A++RFLinkGTW+ESP8266s+PWS_WS7000
Common = KAKUs+3*PVLogger+PWS_TFA_Nexus
plus series of 'satellites' for dedicated interfacing, monitoring & control.
Who is online
Users browsing this forum: Bing [Bot] and 0 guests