UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[babl]

@sborg 3.5.0 ist installiert, fehlerfrei bis jetzt

statistikscript v2.07 ebenfalls installiert, bisher fehlerfrei, alles andere ob die Fehler nun nach Mitternacht weg sind, schreibe ich dir die nächsten Tage.

Update: Fehler sind weg

P.S.

Danke für deine Arbeit.

Gruß

[Rand]

@sborg said in [Linux Shell-Skript] WLAN-Wetterstation:

@boronsbruder sagte in [Linux Shell-Skript] WLAN-Wetterstation:

Meines Wissens sagte @Sborg irgendwann "Mein Skript schreibt nichts in die InfluxDB"

Mehr als einmal
Das macht der Influx-Adapter schon gut und komfortabel, da muss ich nicht nochmals das Rad erfinden.

Lange nicht mitgelesen, lief ja;)

Noch eine (ggf schonmal beantwortete Frage) - wenn das Shell Skript ja keine direkte DB Verbindung hat, warum ist dann die Umstellung auf Influx2 relevant?
Das Interface zu Influx ist dann ja nur der Logging Adapter, der ja sowohl mit Influx 1 als auch 2 umgehen kann (neue Grafana Dashboards sind ein anderes Thema) ?

Und wenn ich schon doofe Fragen stelle - ich nehme an die neueren "Smart" Geräte von Ecowitt (in meinem Fall WittFlow WFC01) werden eher nicht integriert werden oder?
Die pushen ja keine Wetterdaten sondern müssten per API abgefragt oder gesteuert werden, das ist ja ne völlig andere Logik...

[SBorg]

@rand sagte in [Linux Shell-Skript] WLAN-Wetterstation:

Noch eine (ggf schonmal beantwortete Frage) - wenn das Shell Skript ja keine direkte DB Verbindung hat, warum ist dann die Umstellung auf Influx2 relevant?

Nicht zwingend. Guggst du https://github.com/SBorg2014/WLAN-Wetterstation/wiki bei den Werten.
Wenn du die Werte mit Punkt "4" nicht willst/brauchst, benötigst du auch keine InfluxDB. ZB. der Wert "Höchsttemperatur der letzten 24h" liefert die Station/Gateway nicht. Um den aber zu bestimmen brauche ich die Messwerte der letzten 24h = eine Datenbank. InfluxDB werden die meisten schon wegen Grafana haben, also brauche ich keine eigene programmieren. Selbst wenn, würde die nix besser machen (...und jeder Entwickler ist wohl faul, zumindest ich , also warum nicht auf was fertiges zurückgreifen? )

Und wenn ich schon doofe Fragen stelle - ich nehme an die neueren "Smart" Geräte von Ecowitt (in meinem Fall WittFlow WFC01) werden eher nicht integriert werden oder?
Die pushen ja keine Wetterdaten sondern müssten per API abgefragt oder gesteuert werden, das ist ja ne völlig andere Logik...

Gübbet keine doofen Fragen
Da ich, anders als manch Youtuber (nein, das kritisiere ich nicht), nicht davon lebe, ist die benötigte Hardware mein "Privatvergnügen". Soll heißen, ich muss es kaufen und kann es dann gar nicht selbst gebrauchen. Für eine API-Abfrage, welche natürlich implementierbar wäre falls sie zugänglich ist, genügt mir anders als bei den Stationen kein Datenstring den ich nach meinen Wünschen auch manipulieren (also bspw. einen statischen Messwert einpatche, um ihn zu simulieren) kann, braucht es hier schon Hardware.
Ich hatte mal bei Ecowitt zwecks Support/Unterstützung angefragt und sogar eine Zusage bekommen. Leider kam nie etwas an und das Ganze verlief im Sande. Wer also will und Zeit hat kann gerne mal einen Vorab-Kontakt herstellen. Vielleicht wollen sie jetzt ja auch schon gar nicht mehr.

[tritor]

[erledigt]: DPs auf gemischt umgestellt.
Hab seit heute nach Update auf Ver 3.5 folgende Fehlermeldungen im log

simple-api.0
2025-05-26 01:43:13.088	info	State value to set for "0_userdata.0.Wetterstation.Regen_Stunde" has to be type "number" but received type "string"

simple-api.0
2025-05-26 01:43:13.086	info	State value to set for "0_userdata.0.Wetterstation.Sonnenstrahlung" has to be type "number" but received type "string"

simple-api.0
2025-05-26 01:43:13.083	info	State value to set for "0_userdata.0.Wetterstation.Wind" has to be type "number" but received type "string"

simple-api.0
2025-05-26 01:43:13.082	info	State value to set for "0_userdata.0.Wetterstation.Taupunkt" has to be type "number" but received type "string"

simple-api.0
2025-05-26 01:43:13.081	info	State value to set for "0_userdata.0.Wetterstation.Innentemperatur" has to be type "number" but received type "string"

Im wetterstation.js sind die DPs aber auch mit number definiert.
Wie bekomme ich das korrigiert?

[Ein ehemaliger Benutzer]

@tritor

eigentlich ist alles richtig, aber... bei Werten mit Komma oder Punkt wertet der Simple-Api wohl das als String, daher musst du
entweder alle angemeckerten Datenpunkte manuell auf String aendern
oder
die Datenpunkte loeschen, und im Script anstatt Number String schreiben.

[tritor]

@neuschwansteini

und das Statistikskript funktioniert dann weiter wenn Daen als String kommen?

[SBorg]

@tritor Ich habe es oben zwar gelesen, möchte aber trotzdem noch mal für ALLE darauf eingehen.

Die Datenpunkte die angemeckert werden bitte auf gemischt umstellen. "String", wie in der Fehlermeldung, mag zwar auch funktionieren, aber ich konnte den genauen Fehler nicht analysieren. Entweder ist die Datenmenge für den Simple-API zu groß oder es kommt zu einem Timing-Problem. Eigentlich ist ein Wert von 1.2 (also float) immer eine Zahl, selbst 1 (also integer) sollte als Zahl erkannt werden.
Leider wird es mal als Zahl erkannt, mal als Text. Deswegen auch auf "gemischt" stellen, sonst meckert er dann wieder genau anders herum

...has to be type "string" but received type "number"

Naxhteil von "gemischt" gibt es keinen direkten. InfluxDB loggt es als Zahl, History ebenfalls, das Statisk-Script interessiert es ebenfalls nicht. Nur wenn man per Javascript den Datentyp ("typeOf") abfragt erhält man nun nicht mehr "Number".

Ich muss mal schauen ob das mit der Rest-API besser funktioniert. Aber ihr ahnt es sicherlich schon, die Liebe Zeit...

[MartyBr]

@sborg
Ich habe gestern die Ecowitt WG3000A erfolgreich eingebunden. Damit wird die Liste der kompatiblen Geräte wieder größer

[Negalein]

@martybr sagte in [Linux Shell-Skript] WLAN-Wetterstation:

Ecowitt WG3000A

welche ist das? Finde nur eine GW3000

[MartyBr]

@negalein
Ist auch eine GW3000A. Tippfehler, sorry

[Negalein]

@martybr sagte in [Linux Shell-Skript] WLAN-Wetterstation:

GW3000A

Merci

Ah, das ist nur das Gateway.
Was hast du da alles angebunden?

[MartyBr]

@negalein
Das Gateway soll alle Ecowitt Geräte anbinden. Ich habe die alte Wetterstation, die ich mit dem Gateway GW1000A zusammen gekauft hatte ohne Probleme am neuen GW3000 anmelden und in den ioBroker integrieren konnte.
Zusätzlich habe ich den Bodefeuchtesensor DP51 (heisst DP100 bei Froggit) angebunden.

Der GW3000 hat zusätzlich eine LAN-Schnittstelle, das erleichtert die Anbindung wenn man die zusätzliche Sicherheit einer LAN präferiert.
Ich hatte vor dem Umbau nach Kompatibilität und Anbindung recherchiert. Aber der GW3000 unterstützt das gesamte Ecowitt / Froggit Angebot. Die Einrichtung war wirklich einfach.

Edit:
Beim großen Online Kaufhaus mit A*** gerade für ca. ca. 59 € im Angebot.

[Boronsbruder]

@negalein
ist quasi der große Bruder vom GW2000 mit externer Antenne und glaube ich sogar ne SD-Karte ist möglich und in der Regel funktioneren alle Geräte der älteren Gateways.
Zumindest hat der Umstieg bzw. im Moment der Parallelbetrieb des gw1000 und gw2000 ohne Probleme funktionert.
Das GW1000 empfängt nur die Bodenfeuchte-Sensoren für die Steuerung meiner Bewässerung (und die Aussentemperatur weil sonst das Skript von @SBorg zickt :D)
So kannst übrigens auch nen Testlauf wegen Empfang machen. Einfach alle Sensoren in die neue Station einpflegen und dann die alte später abschalten.

Gw3000 Daten im Ecowitt-Shop

[MartyBr]

@boronsbruder
Da war bei mir einfacher. Der GW3000 hat alle Geräte/Sensoren gefunden und automatisch eingelesen.
Und ja, er hat eine SD-Karte, die man Remote auslesen kann. Da läuft wohl ein kleiner Web-Server. Die Abfrage der Web-Schnittstelle ist nun auch per PW gesichert.

[Boronsbruder]

@martybr
Das ist richtig. Ich gehe nur her und vergebe dann für die Anzeige Name und deaktiviere alle freien Slots, dass dort nicht immer nach neuen Geräte gesucht wird.


Nur zum Nachrüsten von neuen Geräten aktiviere ich die Kanäle
Ach ja, ich weiß nicht wie es beim 3000er ist, aber beim 2000er muss man die Regenzeit unter Rain-Totals einstellen. Steht standardmäßig nicht auf Januar und dann wird die Jahresmenge nicht richtig zurückgesetzt:

[MartyBr]

@boronsbruder
Die Einstellung der Rücksetzzeit steht schon per Default am Januar. Der Reset Weekly wird mit Sunday vorbelegt.
Das ist ein interessanter Vorschlag mit dem deaktivieren der freien Kanäle. Dann können sie auch nicht gekapert werden.

Das werde ich so umsetzen, danke für den Tipp.

[Negalein]

@martybr
@Boronsbruder

ich hab die froggit wh4000 se

kann ich die dann also auch am GW3000 anlernen und mir das dumme Display-GW sparen?

[MartyBr]

@negalein
Ich vermute, dass die Ausseneinheit auch mit dem GW3000 funktioniert. Ist aber nur eine Vermutung. Laut Ecowitt funktionieren:

1 - WS85 Sensor Array
1 - WS90 Sensor Array
1 - WS69 Sensor Array
1 - WS80 Sensor Array
1 - WS68 Sensor Array
1 - WH40 Regenmesser
1 - WH57 Blitzdetektor
1 - WH45/WH46 Luftqualitätssensor
1 - WN32 Außen-Temperatur- und Feuchtigkeitssensor
1 - WN32P Innenraum-Temperatur-, Feuchtigkeits- und Drucksensor
4 - WH55 Lecksucher
4 - LDS01 Laser-Entfernungssensor
4 - Jede Kombination von WH41 und WH43 Luftqualitätssensor (PM2.5)
8 - WN35 Blattfeuchtigkeitssensor
8 - Jede Kombination von Temperatursensoren WN34L, WN34S und WN34D
8 - Jede Kombination aus WN31/WN31_EP Temperatur- und Feuchtigkeitssensor, WN30 Temperaturfühler und WN36 Poolthermometer
16 - Jede Kombination von WH51 und WH51L Bodenfeuchtesensor
16 - Jede Kombination aus WFC01 Wasserzeitschaltuhr und AC1100 Smart Steckdose sowie WFC02 Kugelhahn-Zeitschaltuhr

Meines Wissens nach hat die WH4000SE eine WS69 Ausseneinheit.

[Boronsbruder]

@negalein
Ich hab die Ausseneinheit Froggit WH4000SE an nem GW2000 am laufen. Sollte also auch am 3000er gehen.

[MartyBr]

@boronsbruder
@Negalein

Die habe ich auch. Die läuft am GW3000A.