See several attempts to construct an interface between Marstek-battery and Domoticz and other applications. But (whatever the application) a 'clean' setup starts with getting&reading the specification of the interface and it's data-protocol. Therefore: which document is applicable for interface ...

IMHO for a user after installation or after upgrade having a look at Domoticz-display with browser is first sign of confidence: always using latest release of Firefox and GoogleChrome that should not be a big deal. Reversely, no access to Domoticz by browser might be a first sign of trouble ...

Bookworm yes, but Domoticz2025.1 does not run => questionmark & doubt
and therefore my reluctance to upgrade my older RPIs,
and attention to keep those devices up&running by taking precautions to have compatible backup files&images.

Walter, Thinking of one type of accident (= SD-card getting corrupted) your suggested rollback-method as safeguard requires that that last, big backup-file is stored outside the SD-card before the actual upgrade is performed (or similar action): ;-) not for the 'simple' user. By means of Domoticz ...

Only tried upgrade from machines running Domotic_2024.7, first with few Testers running 'beta', and then 'Production'-kernel running 'stable': now (re)learned the hard way that testing must be done over some extended time to catch effects of load, timing, reboot etc. ....... In my configuration ...

Due to the failed upgrade you may doubt the value , but when testing & trying this morning, the following observations related to browser versus processortype and OS-version: - upgraded Raspberry3A_Buster called with GoogleChrome shows Domoticz-window telling that no favorite devices defined etc ...

Today having experienced a total failure of upgrade to Domoticz_2025.1 on a series of Raspberries, perhaps suggestion to have available for user_download readytogo images of some latest, superstable, legacy Domoticz_versions as occurring at 'thresholds'? Easy/convenient as references for safe ...

Have 9 RPIs running in a variety of Raspberries of types3A, 3B and 02W with OS= Buster or BullsEye. 1 RPI4B with Bookworm, reporting OpenSSL 3.0.16 11 Feb 2025 (Library: OpenSSL 3.0.16 11 Feb 2025) Paid attention to the warning to have OpenSSL3 fitted prior to trying upgrade, but (in hindsight ...

Sure some functions will depend on a related version of OpenSSL.

But plenty of userprograms probably[?] will never touch it.

is a hint possible what kind of functions will certainly need the shift to OpenSSL3.0, and which not?
Or a hint to some description dealing with that aspect?

'Devil is in details' As indicated in first message and subsequent additions in this thread, for simple, closed circuit, mutual data transfer have installed VSFTPD on all Raspberries in my LAN, all of older generation with Buster or Bullseye for OS. Now added a Raspberry 4B with Bookworm as OS, and ...

Try this weblink as introduction & explanation for the scripts earlier in this thread.

MetOffice-Datahub meanwhile seems to concentrate on meteo-info in the UK: not very appealing for meteo-buds 'on the continent'. And no readback in sight for the PWS-data contributed to MetOffice/WOW ...... Sensing a move of MetOffice/WOW to become 'more commercial' and less volunteer-oriented: suck ...

As experiment with LoraWAN a device type LSN50v2D20 is feeding data to TTN's network & servers: - data from 1 analogue input through ADC - data from 3 thermosensors DS18B20 (of which 1 actively connected) 2 Outputs from TTN: - Webhook towards Datacake.be periodically producing a csv-file - Webhook ...

Looking how to integrate a weatherstation through LoraWAN to Domoticz. From the TTN_Forum an example-script is available for MQTT-interfacing. At Domoticz-side as 'hardware' an interface exists called MQTT AutoDiscovery Client Gateway with LAN . Any description (or forum messages) available which ...

Question remains valid, also because almost impossible to reach station-owner unless (s)he has a private website enabling contact.

The present weather invites to revisit 'parked' projects ……. Old thread, but for understanding have to step back to the point previously stopped. Looking in Wiki for TTN combined with MQTT, the requirement pops up that CayenneLPP to be used for datatransport: yet another protocol on the route …. ...

Users/owners of Davis weathersystems often upload their data to the WeatherlinkCloud, providing readout via a Dashboard. Also possible for that owner to read back data via the api_v2 . Not having a Davis setup you can still have an account for that WeatherlinkCloud, and then it is possible to read ...

You are right: sorry to have mixed up Google and Highcharts ........ With my latest message only intended to tell that in Domoticz the generation of the graphs is still OK for viewing in Domoticz, but that 'problem' seems to be export of the graph, which can be 'escaped' by application of ...

There seems to be something different than just a change of policy by Google..... Graphics appear 'undisturbed' ( in my opinion meaning that Highcharts still applied for the compilations), but only export seems to be affected by the changes at Google. For myself pragmatically solved by application ...

5channel-version from Bresser might be compatible, like
Typenumber: 7009993
EAN: 4007922152097
WEEE-Reg.-Nr. DE 34323861

This device also a candidate:
from TFA offered as replacement for obsolete type 30.3150, modified by Seller for larger range coverage .....
.