LoxBerry-Plugin: FOSHKplugin - Wettergateway Froggit DP1500 / Ecowitt GW1000 anbinden

[olicat]

Hi!

I wrote to Ecowitt about this. I actually think this is a problem with the current firmware. Ecowitt actually tinkered with the battery values. It is quite possible that the transmission of wh40batt was accidentally deactivated. I'll get in touch with you tomorrow when Lucy has answered.

FOSHKplugin does not use the GW1000 API but only uses the values that are transmitted via the custom server. So I can also support other weather stations (HP3501, WH2910, HP2551, ...).
With the GW1000 API I would be limited to WH2650 and GW1000.

Regards, Oliver

[olicat]

wswarning will only be sent if status is changed. Both with a 0 and a 1 message.
However, you should make sure that your virtual input in Loxone Config is of the analog type and not digital.

[olicat]

According to Ecowitt, the sensor WH40 cannot tell the battery level at all, which is why this was removed with firmware v1.6.6 for the GW1000. Thus the level is neither transmitted via custom server nor to Ecowitt or is visible in the live view of WS View.
Strange ...
Have you ever seen a change with wh40batt?

[Gustaw_]

Nope, never seen any change in wh40batt level but honestly also no change in wh68batt after almost one year of using it. Regardless, thanks for updating and look that I need to remove rain sensor's battery check from my program then...

[Gustaw_]

yep, looks that it works as designed but... I found that UDP input in loxone always keeps last received value even after server stop receiving data via UDP or loxberry is restarted.
So my server have stuck with wswarning flag set to 1 because never receive info about changing it to 0. Potentially due to network instability or maybe because loxone or loxberry was restarted when GW1000 was reconnecting.
As workaround for such issue you can setup Receiving timeout flag on virtual input (e.g 5 min) so in theory everything is working fine after reboot, but only until wswarnig change its state from 0 to 1, then Loxone server will always send connection error message 5 minutes after receiving last gateway status update.
Maybe FOSHK plugin should send wswarning flag periodically together with weather data to resolve such problems in the future ? Just a feature request for next release.

[olicat]

Hi!

I don't know what happened to you, but the wswarning status is set correctly as far as I can tell. The status survives the restart of the plugin (by design). The wswarning status is reset as soon as the weather station has sent again. You just have to make sure that the virtual input is configured as analog and not digital in Loxone Config.

The permanent transmission of the status messages would lead to higher traffic without any real benefit. You can, however, query the current status at any time using a virtual-out command. There is the FOSHK-getStatus command in the Loxone template, which instructs the plugin to report the status via UDP message SID=FOSHKplugin,Plugin.getstatus.
You could even automate that.

But I will think about sending the status as an option. This option already exists for UDP forward (FWD_TYPE = UDP).

Regards, Oliver

[Gustaw_]

Hi,

thanks for pointing FOSHK-getStatus workaround, need to think about it but honestly I don't like to mix UDP/HTTP requests.
Sending status recurrently as an option would be perfect resolution...

Just to clarify why I'm rising this topic... I fully agree with you that from software development perspective permanent transmission of the status messages don't make sense.

But based on my networking background and practical experience, there are several reasons why Loxone server can potentially not receive UDP message (network delays, packet lost, switch or other device reboot etc.). Working on IoT you need also to consider how long each of your devices are booting up and reconnecting to the network otherwise your system may get stuck in non-stable state after power down 😀

So personally I don't care abut impact on network traffic (honestly additional 10 bytes per 1 minute is like nothing for typical GB ethernet), but rather focusing on network reliability problems as being critical in most of IoT environments. Unfortunately if Loxone server will not receive once UDP message entire IoT logic stop working. So without being for 100% sure that sent message is delivered do the server, resending statuses recurrently is easiest option. Otherwise you need to complicate Loxone logic and making server more busy, so far my program uses 95% of server's memory...

Once again thanks for your help and support

Regards, Wojtek

[olicat]

Hi!

Got your point.
Will think about this.

thanks for pointing FOSHK-getStatus workaround, need to think about it but honestly I don't like to mix UDP/HTTP requests.

The virtual outs are UDP of course.
So you could stay at UDP-only
Regards, Oliver

[Gustaw_]

Got it, looks fine will add additional loop in my Loxone program, so I can use then FOSHK-getStatus and receive plugin's keep alive info even more frequently. It'll help me to clean up system errors messaging logic... Now it's really difficult to recognise and report properly real root cause of the problems eg. sensor low battery, IP connection problems or FOSKH plugin stop responding.

Yes, I know somehow this is very unusual approach 😀

[olicat]

Hi!

Was könnte man denn mit den Daten einer Wetterstation sinnvoll anfangen, wenn diese die Daten per MQTT bereitstellt?
Gibt es da Bedarf oder use-cases?

Ich überlege noch, wie ich den mit FOSHKplugin v0.08 kommenden MQTT-Forward sinnvoll testen kann ...
Hinweise?

Schönes Wochenende!

Oliver

[Christian Fenzl]

Aus meiner Sicht ist es erstmal eine alternative Übertragungsmethode zum Miniserver, mit allen Features wie Cache, Übertragung per HTTP oder UDP, Filtern, Übertragungsmöglichkeit an mehrere Miniserver gleichzeitig, automatische Erkennung und Neuübertragung wenn der MS neu startet, automatisches Zerlegen einer Json-Nachricht usw.

In zweiter Linie hast du einen standardisierten Übertragungsweg zu allen SmartHome-Programmen wie Node-Red, ioBroker, Home Assistant, FHEM,...

Programmatisch ist reines Senden an MQTT ein Fünfzeiler (vier Zeilen sind das Einstellen der Credentials), und wenn du alle Daten in einem Named Array / Objekt / Hash hältst, ist mit einem encode_json in einer Zeile das ganze Dataset übertragen.

[Christian Fenzl]

PS: Mit Python am LoxBerry mit MQTT ist diese Routine „Vorzeigecode“, wie man sich die MQTT-Credentials vom MQTT Gateway holt:

https://github.com/joesie/GPIO/blob/89dc3cda05cb4e7efad572589609230fe47ea87e/bin/gpio2mqtt.py#L102

Dies wird immer funktionieren, und ich garantiere, dass das auch dann noch funktioniert, wenn das Plugin in den LB-Core wandert.
Das ist die textuelle Beschreibung dazu: https://www.loxwiki.eu/display/LOXBE...on,Node.js,etc.)

[olicat]

Danke Christian,

genau diese Standardisierungs-Geschichte mit der möglichen Anbindung unzähliger anderer Dienste war für mich der Trigger, MQTT als weiteres Export-Format einzubauen.
Der präferierte Weg zum Datenaustausch bleibt aber UDP - nur so bin ich nicht abhängig von anderen Diensten - wie etwa dem MQTT-Broker.

Primär suche ich einen MQTT-Client, der mir die Daten schnell und vielleicht auch hübsch anzeigt, um ein Gefühl zu bekommen, ob ich da hinsichtlich Datenformat, QoS oder retain noch was anpassen sollte.
Momentan teste ich das nur mit dem Incoming Overview des MQTT-Gateway-Plugins.
Fällt Dir dazu was ein?

Gruß, Oliver

[Christian Fenzl]

Ich verwende MQTT-Spy unter Windows, das ist Java-based. (Screenshots ganz unten: https://www.loxwiki.eu/display/LOXBE...ogger+Receiver)

MQTT Explorer hab ich glaube ich auch installiert.

Am Android Tablet hab ich mal mit IoTMQTT bissl rumgespielt.

[olicat]

Vielen Dank fuer die hilfreichen Hinweise!
:-)
Ich habe jetzt mal eben die Android-App auf dem Phone installiert und es sieht passend aus.
Also FOSHKplugin kann jetzt auch MQTT senden ...

Auch huebsch: ich habe parallel sowohl die metrischen als auch die imperialen Werte per MQTT jederzeit im Zugriff.

Gruss, Oliver

[olicat]

Hi!

Ein (weiterer) Ausblick auf die kommende Version v0.08 von FOSHKplugin:

• 50 Weiterleitungsziele für den custom server
• besseres Logging mit Log-Leveln
• deutlich bessere Übertragungssicherheit dank zweifacher Wiederholung im Falle eines Fehlers
• Support weiterer Wetterdienste (wetter.com, weather365.net, wettersektor.de)
• Export als realtime.txt (Cumulus) und clientraw.txt (Weather Display) - somit Unterstützung weiterer Programme und Dienste
• Export des jeweils aktuellen Datensatzes als TXT- und/oder CSV-Datei - Datei wird jeweils bei Empfang neuer Daten überschrieben
• native Unterstützung von MQTT - Daten können also per Forward an einen MQTT-Broker geschickt werden
• Berechnung zusätzlicher Werte (cloudbase, sunhours, min/max-Werte mit Zeitangabe)
• Länge der UDP-Nachrichten kann begrenzt werden - bei längeren Datagrammen erfolgt der Versand mehrerer partieller Sendungen
• bei Einsatz eines WH45 kann eine Push-Benachrichtigung erfolgen, wenn CO2-Wert eine konfigurierrbare Grenze übersteigt

Wer bereits jetzt schon dringend eine der obigen Funktionen testen möchte, schreibe mir bitte ein PM.
Der Beginn des öffentlichen Beta-Tests wird noch einen Moment dauern.

Gruss, Oliver

[ChrisR]

Wow!!!
Du bist der Hammer

Danke Oliver

[olicat]

Gustaw_ :

So personally I don't care abut impact on network traffic (honestly additional 10 bytes per 1 minute is like nothing for typical GB ethernet), but rather focusing on network reliability problems as being critical in most of IoT environments.

One of the new features of the upcoming v0.08 fullfills your wish:

With Config\UDP_STATRESEND = n, a cycle time (n seconds) can be defined in which the warning messages are sent regardless of status changes

Please let me know if you'd like to try this before the public beta test.

Regards, Oliver

[Gustaw_]

Thanks a lot, great news. I'm happy to test this feature even in pre beta version 😀

[olicat]

Eine Frage an die MQTT-Experten oder regelmaessigen MQTT-Nutzer hier ...

Sollte man bei jedem Eingang von Daten der Wetterstation alle topics neu schreiben, jeweils nur die Änderungen schreiben oder das konfigurierbar halten?
Ich kann allen drei Optionen etwas abgewinnen; finde aber auch jeweils Nachteile: erhoehter Traffic, moeglicher Verlust von Meldungen, erhoehter Konfigurationsbedarf.
Aktuell ist es konfigurierbar vorgesehen - es werden nur die Aenderungen uebertragen und zusaetzlich alle n Sekunden das Komplett-Set - ich suche aber noch eine sinnvolle default-Einstellung.
Wuensche? Empfehlungen? Hinweise?
Danke!

Gruss, Oliver

[Christian Fenzl]

In Verbindung mit MQTT Gateway: Völlig egal, LoxBerry unterdrückt standardmäßig das Übermitteln von gleichen Einzelwerten (mit verschiedenen Logiken, zb jede Stunde wird eine Übertragung von dir trotzdem übertragen, und LoxBerry erkennt, wenn der MS neu startet und überträgt dann auch wieder).

Dem Broker selbst ist es herzlich egal, wenn du Daten regelmäßig sendest. Solange du nicht über 1 Mio. kommst, da wird man’s womöglich merken 😉

[coldice]

Mals ne kurze Frage etwas abseits von Loxberry: Hat noch jemand mit der Firmware 1.6.6 der Wetterstation ( bei mir WH3000) das Problem das die Aussenluftfeuchte nur 10% anzeigt ? Daraus resultierend die Berechnung des Taupunktes auch nicht stimmt ....

Ich habe bereits 2 Stationen wo dies so ist.

Vom Froggit Support wurde mir gesagt ich solle die Batterien tauschen .... Was ich aber quatsch finde denn angeblich braucht die Station die Batterien nur für den Nachbetrieb. Am Tag versorgt die Solarzelle die Station. Folglich müsste der Wert dann am Tag stimmen. Und warum stimmen alle Werte nur die Feuchte nicht ?

Kann diesen Effekt noch jemand beobachten ?

[olicat]

Nein, ich habe dazu bisher nichts irgendwo lesen koennen und fuerchte, das ist ein Hardware-Problem auf Deiner Seite. Meine Aussenluftfeuchte liegt aktuell bei 91% (Y-Sensor WH65) am DP1500 mit v1.6.6..
Oliver

[KeLa]

Kann ich auch nicht bestätigen. Ich habe zwar die froggit HP-1000SE aber die Y-Ausseneinheit sollte bei allen gleich sein. Wenn ich mich recht entsinne gab es vor kurzem nur ein neues Update fürs WIFI zumindest hat es mir die WS View App so angeboten. Ansonsten nutze ich die FW 1.7.1

Konnte man die Ausseneinheit nicht separat resetten? 10% ist wohl das Minimum was sie anzeigen kann. Das nun zwei Ausseneinheiten teilweise
unabhängig voneinander aussteigen wäre aber ein verdammt dämlicher Zufall.

Ich liege mit der Aussenluftfeuchtigkeit aktuell bei 75% bei 2,4°C

Gruß
Lars

[olicat]

Hallo!

Der öffentliche Betatest der neuen Version v0.08 von FOSHKplugin hat begonnen.
Ich denke, es sind ein paar nützliche Erweiterungen enthalten. Näheres dazu im Changelog.
Nutzer, die die neuen Features nicht benötigen und mit der Version v0.07 soweit zufrieden sind, können gern auf altem Stand verbleiben.

Der öffentliche Beta-Test dient der Suche nach bisher unentdeckten Fehlern - hier läuft die neue Version seit einigen Wochen bei einer Handvoll Nutzern ohne Probleme.
Es gibt aber sicherlich ein paar Einsatzszenarien, die noch nicht ausgiebig im internen Test geprüft wurden.

Zum Update bitte wie üblich in der LoxBerry-Plugin-Verwaltung als URL diesen Link

https://foshkplugin.phantasoft.de/fi...-0.0.8Beta.zip

einfügen und installieren. Bestehende Settings sollten erhalten bleiben.

Oliver