Weatherflow Tempest Wetterstation

Symcon PHP-Module (Diskussion)
21

Ich habe mal versucht herauszufinden, ob ich Chart geht oder nicht irgendwie eingrenzen kann. Es ist etwas verwirrend.

Nachdem du sagtest, das Dashbord ist mehr als Webseite zu sehen, habe ich die Browser auch verschiedenen Geräten gestestet.

  • mit Android Geräten geht es nach anfänglichen Problemen wohl nun durchgängig. Auch als HTML-Seite in IPSView
  • bei Windows 11 ist es etwas komplizierter. Da gibt es von Gerät zu Gerät schon unterschiede. Mein Symcon-PC wollte es gestern garnicht, heute früh hat es nun funktioniert mit IPSView. Aber mit Chrome und Edge keine Charts. Seltsam ist hier auch, dass meine eigenen Highcharts nun hier nur noch sporadisch funktionieren. Allerdings habe ich auf einem anderen Window-PC weder keine Probleme mehr - im Gegensatz zu gestern. Hier geht Chrome, Edge, IPSView und meine eigenen Highcharts. Updates und Patche habe ich schon mal nachgezogen. Ohne Erfolg. Du nutzt für die Charts ja auch Highcharts.

Nun mal zu den Charts. Mit der neuen Höheneinstellung sieht das schon besser aus. Vielleicht kannst du bei Station Pressure die Y-Achse etwas einschränken, Änderungen sind hier garnicht erkennbar. Auch ist bei mir die Schriftgröße für die Werte sehr groß. Da ist bei 1000er Werten kaum mehr Platz. Vielleicht kannst du auch die Schriftgröße anpassbar machen?

Nun werde ich mal weiter suchen, ob ich noch was zum unterschiedlichen Verhalten der Charts feststellen kann.

alles in allem - tolle Umsetzung vom Skript zum Modul. Danke

22

Schau dir mal die neue Beta an. Ich habe die beiden Änderungswünsche eingebaut

Viel Spass

23

Hab Dein Modul jetzt auch mal neben dem alten Skript am Laufen. Super Arbeit, Danke.

Aber

  • bei Power-Booster extern kommt bei mir “false” obwohl ich einen dran habe, Bit 10 und 11 ist “true”
  • “sensor_status” steht bei 1536, im alten skript auf 0
24

Ich schau mir das bei Gelegenheit an, Danke fuers feedback

25

Ich habe gerade mal die UDP API dazu angeschaut: WeatherFlow Tempest UDP Reference - v171

  • Bit 10 ist somit true, wenn ein Power-Booster vorhanden ist (das kannte ich auch noch nicht),

  • Bit 11 ist immer noch nicht dokumentiert,

  • Bit 16 ist true, wenn die Batterien des Power-Boosters leer sind,

  • Bit 17 ist true, wenn der Power-Booster mit externer Spannung versorgt wird

    die 1536 ist mit Power-Booster somit korrekt.

Das alte Skript hat nur bis Bit 9 ausgewertet, weil es die für den Power-Booster damals noch nicht gab. Das hatte ich bei mir lokal angepasst.

@BestEx vielleicht kannst du das im Modul noch ergänzen.
Danke

Gruß Rainer

26

@BestEx mit der Anpassung bei den Charts sieht man nun mehr Details. So ist auch zu erkennen, dass die Uhrzeit nicht MEZ ist (-1h). Auch werden die Charts nur soweit aktualisiert, wie sich die Werte ändern. Bei Precip Accumulated ist in den Regenpausen nun eine aufsteigende Linie zu erkennen.

image
image385×266 50.2 KB

Vielleicht geht da auch ein Balkendiagramm? Ich habe die als Zähler geloggt. Sieht in Symcom so aus:

image
image826×349 29 KB

Gruß Rainer

27

@admin-diamir @erpe
1.) Power Booster Bits angepasst

2.) Precip Accumulated = Bar Chart

3.) Zeit Zonen Auswahl in der GUI

Neue Beta

28

Danke @BestEx,
es sieht so aus, dass bei den Booster Bits was durcheinander gekommen ist. Da bist du um ein Bit “verrutscht”. Fängt Bit 1 bei dir mit 0 an?
Das ist mein Sensorstatus binär 10000011000000000 = Booster vorhanden, Bit 11, Booster extern versorgt auf true.

Für den Bar Chart muss ich auf Regen hoffen… :wink:
”Lightning Strike Count” ist auch besser mit Bar Chart und Zähler-logging

mit Zeitzone passt nun auch die Uhrzeit. :+1:

Bei den Charts habe ich noch festgestellt: wenn die Variablen nicht aktualisiert werden, weil “0”, bleiben die stehen (Regen, Helligkeit, UV und Solarstrahlung). Da es für den aktuellen Zeitstempel keinen Wert gibt, müsstest du da den letzten Wert nochmal mitgeben. Highcharts zeigt eben nur die Werte an, die es bekommt.

danke für’s umsetzen.

Gruß Rainer

29

@erpe Ich habe dich nicht vergessen, SRY bin im Moment ziemlich beschäftigt aber ich kümmere mich drum

30

Kein Problem, manchmal haben andere Dinge eine höhere Priorität.

31

@erpe Rainer ich habe all deine Punkte jetzt in der aktuellen Beta gelöst. Tut mir leid das das so lange gedauert hat.

32

@BestEx, ich bin auch erst jetzt zum Testen gekommen.
Ich hatte generelle Probleme mit den Highcharts. Wenn ich die Visu oder IPSView mit der IPv4-Adresse aufrufe, bekomme ich die Highcharts nicht angezeigt. Wenn ich stattdessen den Rechnername nehme funktioniert es.
Schon seltsam…

Sieht soweit erstmal aus, dass noch alles funktioniert.
Den Regenchart hast du noch nicht auf Bargraph geändert? Der zeigt bei mir immernoch Linienchart an.
Könntest du für die Chartnamen die der Variablen verwenden? Dann könnte man sich das entsprechen auch in anderen Sprachen anzeigen lassen :wink:

Danke, ich teste mal weiter…

Gruß Rainer

33

Hallo @erpe Ich habe eine neue Version erstellt und hoffe damit deine Punkte erledigt zu haben.

Mein KI hat zu deinem IP/Namen Problem folgende Aussage getroffen

Das Verhalten, dass Highcharts über den Rechnernamen funktioniert, aber über die IPv4-Adresse blockiert wird, ist ein bekanntes Phänomen moderner Webbrowser. Es liegt meist an den verschärften Sicherheitsrichtlinien für sogenannte „Secure Contexts“.

Hier sind die wahrscheinlichsten Ursachen für dieses Verhalten:

1. Secure Context & PWA-Anforderungen

Da wir in das Modul eine Service Worker-Funktionalität und ein Web-Manifest eingebaut haben, stuft der Browser die Seite als „Progressive Web App“ (PWA) ein. PWAs haben extrem strikte Sicherheitsanforderungen:

  • Sie dürfen nur in einem „Secure Context“ ausgeführt werden.

  • Ein Secure Context ist entweder https://, localhost oder 127.0.0.1.

  • Eine lokale IP-Adresse wie 192.168.x.x wird von Browsern (insbesondere Chrome) standardmäßig als unsicher eingestuft.

  • Der Clou: Ein Rechnername (Hostname) wird in lokalen Netzwerken oft anders behandelt oder über lokale Zertifikate/DNS-Einstellungen eher als vertrauenswürdig akzeptiert als eine nackte IP-Adresse.

Wenn der Browser die Verbindung über die IP als „unsicher“ markiert, blockiert er das Laden externer Scripte von CDNs (wie code.highcharts.com), um „Man-in-the-Middle“-Angriffe zu verhindern.

2. CORS (Cross-Origin Resource Sharing) & Referrer

Einige CDNs und JavaScript-Bibliotheken prüfen den Referrer (wer fragt die Datei an?).

  • Anfragen von einer IP-Adresse (192.168…) werden oft restriktiver behandelt als Anfragen von einem Hostnamen.

  • Wenn Highcharts intern versucht, weitere Module (wie windbarb.js) nachzuladen, schlägt dies fehl, wenn die Basis-URL (die IP) vom Browser für Cross-Origin-Anfragen gesperrt ist.

3. Mixed Content (HTTPS vs. HTTP)

Falls du IP-Symcon über den Rechnernamen mit einem (selbstsignierten) Zertifikat ansprichst, über die IP aber nur per reinem HTTP (Port 3777), blockiert der Browser sogenannten „Mixed Content“.

  • Eine HTTP-Seite darf keine Scripte über HTTPS (https://code.highcharts.com) nachladen. Da das Modul die Highcharts-URLs fest mit https vorgibt, verweigert der Browser bei einem HTTP-Aufruf der Visu den Dienst.

4. IP-Symcon Connect Dienst

Wenn du den Hostnamen nutzt, nutzt du eventuell (unbewusst) den Connect-Dienst (xxx.ipmagic.de) oder eine lokale DNS-Auflösung, die ein gültiges SSL-Zertifikat mitliefert. Über die IPv4-Adresse ist ein Zertifikats-Match technisch unmöglich (da Zertifikate auf Namen ausgestellt werden), weshalb der Browser in den Sicherheitsmodus schaltet.

Zusammenfassend: Es ist kein Fehler in deinem Code oder dem Modul, sondern eine Sicherheitsmaßnahme deines Browsers. Die Nutzung des Hostnamens oder des Connect-Dienstes ist der empfohlene Weg, um die volle Funktionalität (Highcharts, Service Worker, Biometrie) stabil zu nutzen.

34

Danke Artur für die Erklärung zur Blockade von Highcharts.
Das es mit dem Rechnernamen funktioniert, reicht erstmal. Das über den Connect Dienst zu machen, halte ich “lokal” nicht für sinnvoll.

Aber ein anderes Problem habe ich noch mit der neuen Version. Wenn das Dashboard im Browser oder in IPSView längere Zeit geöffnet ist, schmiert die Webseite mit “Out of Memory” ab, oder IPSView wird neu gestartet. Das kann man im Taskmanager auch schön beim Speicherverbrauch des Browsers sehen.

Hast du dafür eine Erklärung/Lösung?

Die Chartnamen und Bargraph funktionieren nun. Danke

Gruß Rainer

35

@erpe Hallo Rainer, Die KI hat da eine Vermutung. Ich habe eine neue Version eingestellt versuch mal

Gruß Artur

36

Hallo Artur, das war es noch nicht. Speicher läuft immer noch hoch und endet mit “Out of Memory” in Chrome

Gruß Rainer

37

@erpe vielleicht liegt es an der Datenmenge die ich aus dem Archiv hole. Wie sind deine Einstellungen (24 Std. ?, alle 60 sek. ?) Im Moment nehme ich Rohdaten aus dem Archiv, ich könnte auch auf die Aggregation zurückgreifen ?

38

@erpe Rainer ich habe noch Optimierungen/Fehler gefunden. Der Ajax teil hat die Daten unabhängig von der Timer Einstellung ständig neu geladen.

Ich habe weiterhin in der Dashboard-Chart-Erzeugung die Speicherprobleme behoben, indem ich die Datenmenge pro Chart stark begrenzt habe:

  • Keine „unlimited“ Archive-Abfragen mehr: AC_GetLoggedValues(..., 0) wurde ersetzt durch eine feste Obergrenze an Punkten (z.B. 800 für normale Charts).

  • Rapid-Wind separat behandelt (Option A): Für Wind_Speed und Wind_Direction_Rapid wird statt 24h nur noch ein 3-Stunden-Fenster verwendet, dafür mit etwas höherem Cap (z.B. 1200 Punkte), damit die schnelle Aktualisierung sichtbar bleibt.

  • Windbarbs konsistent: Die zusätzliche Speed-Historie für Barbs nutzt dieselbe Zeitspanne und denselben Punkt-Cap wie die Richtungsserie, damit kein unnötiger Datenballast entsteht.

Ergebnis: Deutlich kleinerer HTML/JS-Payload, keine „Allowed memory size exhausted“ (32MB) mehr, und Rapid-Wind bleibt trotzdem flüssig sichtbar.

39

@BestEx Artur, das Speicherproblem besteht immer noch (nach einigen Stunden) in IPSView und Chrome. Ich lasse es jetzt mal in Edge laufen…

Ich habe keine Rapid-Variablen für das Dashboard im Einsatz.

40

@erpe Vielen Dank fürs Feedback. Ich kann den Fehler mittlerweile auch bei mir reproduzieren, es dauert halt immer eine Zeitlang. Behalte ein Auge auf die Beta’s, ich poste wenn ich glaube das es eine Verbesserung gibt

1 „Gefällt mir“