NEWS
[Linux Shell-Skript] WLAN-Wetterstation
-
Ok, danke...
Also entweder direkt Homematic oder die von Conrad...
Ohne Windrichtung geben die sich beim Preis ja nicht viel -
Arrgh, Mist, Denkfehler...
23:58 Uhr Trigger ist dann CET, was für die Station 0:58 Uhr UTC bedeutet (Sommerzeit dann 1:58 Uhr). Da ist auf jeden Fall der Wert der Station immer schon genullt :(Vergesst die V0.1.4 Beta, dass funktioniert so keinesfalls...
LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
Arrgh, Mist, Denkfehler...
23:58 Uhr Trigger ist dann CET, was für die Station 0:58 Uhr UTC bedeutet (Sommerzeit dann 1:58 Uhr). Da ist auf jeden Fall der Wert der Station immer schon genullt :(Vergesst die V0.1.4 Beta, dass funktioniert so keinesfalls...
@SBorg mal so nebenbei, man muss doch an der Station, Sommer/Winterzeit incl Zeitzone manuell einstellen...(hatte ich nämlich vergessen zu ändern:face_palm: )
übrigens gibts mal wieder ein Software update (WS VIEW)...gerade geladen
umgestiegen von Proxmox auf Unraid
-
@SBorg mal so nebenbei, man muss doch an der Station, Sommer/Winterzeit incl Zeitzone manuell einstellen...(hatte ich nämlich vergessen zu ändern:face_palm: )
übrigens gibts mal wieder ein Software update (WS VIEW)...gerade geladen
@crunchip Man merkt so langsam, dass ich im Trüben rumstochere.. ;)
Wahrscheinlich ist die Umstellung nur für die Uhrzeit am Display. Trotzdem müsste ich jetzt Winter-/Sommerzeit berücksichtigen, nur wie lange gibt es sie noch...
Ich werde es vom externen Trigger auf einen internen umstellen. Dann wird automatisch um 23:58 Uhr UTC addiert. Dann ist CET/CEST völlig egal. Ich muss dann nur verhindern falls bspw. zwei mal um 23:58 Uhr ein Datenpaket eintrudelt (bei 16 Sek. könnten es sogar drei sein), dass mehrmals für den Tag die Menge aufsummiert wird. Muss ich also noch den "tc" abfragen, ob ber älter als x Minuten ist...LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@crunchip Man merkt so langsam, dass ich im Trüben rumstochere.. ;)
Wahrscheinlich ist die Umstellung nur für die Uhrzeit am Display. Trotzdem müsste ich jetzt Winter-/Sommerzeit berücksichtigen, nur wie lange gibt es sie noch...
Ich werde es vom externen Trigger auf einen internen umstellen. Dann wird automatisch um 23:58 Uhr UTC addiert. Dann ist CET/CEST völlig egal. Ich muss dann nur verhindern falls bspw. zwei mal um 23:58 Uhr ein Datenpaket eintrudelt (bei 16 Sek. könnten es sogar drei sein), dass mehrmals für den Tag die Menge aufsummiert wird. Muss ich also noch den "tc" abfragen, ob ber älter als x Minuten ist...@SBorg
WS_POLL ist auf 16Hier die Aufzeichnung von der Raspberry ( dort läuft nur dein Skript) , zu Synology wo ioBroker ist :
hier ist die Aktualisierung , jede 30 sek.
12.02.2020 18:05:50 false simple-api.0 2020-02-12 18:05:59.691 12.02.2020 18:05:20 false simple-api.0 2020-02-12 18:05:25.176 12.02.2020 18:03:50 false simple-api.0 2020-02-12 18:03:59.549 12.02.2020 18:03:20 false simple-api.0 2020-02-12 18:03:25.084 12.02.2020 18:01:50 false simple-api.0 2020-02-12 18:01:59.482 12.02.2020 18:01:20 false simple-api.0 2020-02-12 18:01:25.034 12.02.2020 17:59:50 false simple-api.0 2020-02-12 17:59:59.386 12.02.2020 17:59:20 false simple-api.0 2020-02-12 17:59:24.956 12.02.2020 17:57:50 false simple-api.0 2020-02-12 17:57:59.193 12.02.2020 17:57:20 false simple-api.0 2020-02-12 17:57:24.763 12.02.2020 17:55:50 false simple-api.0 2020-02-12 17:55:59.177 12.02.2020 17:55:20 false simple-api.0 2020-02-12 17:55:24.743 12.02.2020 17:53:50 false sql.0 2020-02-12 17:54:54.975hier ein Neustart von der Raspberry um zu sehen ob der Abruf sich ändert :
hier ist die Aktualisierung , jede 60 sek. / 30 sek. / 60 sek.
.12.02.2020 18:19:50 false simple-api.0 2020-02-12 18:19:53.802 12.02.2020 18:19:20 false simple-api.0 2020-02-12 18:19:32.322 12.02.2020 18:18:20 false simple-api.0 2020-02-12 18:18:28.708 12.02.2020 18:17:20 false simple-api.0 2020-02-12 18:17:25.180 12.02.2020 18:15:50 false simple-api.0 2020-02-12 18:16:00.567 12.02.2020 18:14:50 false simple-api.0 2020-02-12 18:14:57.002 12.02.2020 18:13:50 false simple-api.0 2020-02-12 18:13:53.489 12.02.2020 18:13:20 false simple-api.0 2020-02-12 18:13:31.998 12.02.2020 18:12:20 false simple-api.0 2020-02-12 18:12:28.503 12.02.2020 18:11:20 false simple-api.0 2020-02-12 18:11:25.035 12.02.2020 18:09:50 false simple-api.0 2020-02-12 18:10:00.476und nochmal ein Neustart :
hier ist die Aktualisierung , 120 sek. / 60 sek. / 30 sek. / 60 sek.
12.02.2020 18:32:20 false simple-api.0 2020-02-12 18:32:28.679 12.02.2020 18:31:20 false simple-api.0 2020-02-12 18:31:25.186 12.02.2020 18:29:50 false simple-api.0 2020-02-12 18:30:00.645 12.02.2020 18:28:50 false simple-api.0 2020-02-12 18:28:57.053 12.02.2020 18:27:50 false simple-api.0 2020-02-12 18:27:53.538 12.02.2020 18:27:20 false simple-api.0 2020-02-12 18:27:32.101 12.02.2020 18:26:20 false simple-api.0 2020-02-12 18:26:28.615 12.02.2020 18:25:20 false simple-api.0 2020-02-12 18:25:25.135 12.02.2020 18:23:50 false simple-api.0 2020-02-12 18:24:00.539 12.02.2020 18:22:50 false simple-api.0 2020-02-12 18:22:57.034also verschiedene Zeiten…. :disappointed:
EDIT :
hier die weitere Laufzeit nach 18:32 UhrSynology 918+ 16GB - ioBroker in Docker v9 , VISO auf Trekstor Primebook C13 13,3" , Hikvision Domkameras mit Surveillance Station .. CCU RaspberryMatic in Synology VM .. Zigbee CC2538+CC2592 .. Sonoff .. KNX .. Modbus ..
-
@SBorg
WS_POLL ist auf 16Hier die Aufzeichnung von der Raspberry ( dort läuft nur dein Skript) , zu Synology wo ioBroker ist :
hier ist die Aktualisierung , jede 30 sek.
12.02.2020 18:05:50 false simple-api.0 2020-02-12 18:05:59.691 12.02.2020 18:05:20 false simple-api.0 2020-02-12 18:05:25.176 12.02.2020 18:03:50 false simple-api.0 2020-02-12 18:03:59.549 12.02.2020 18:03:20 false simple-api.0 2020-02-12 18:03:25.084 12.02.2020 18:01:50 false simple-api.0 2020-02-12 18:01:59.482 12.02.2020 18:01:20 false simple-api.0 2020-02-12 18:01:25.034 12.02.2020 17:59:50 false simple-api.0 2020-02-12 17:59:59.386 12.02.2020 17:59:20 false simple-api.0 2020-02-12 17:59:24.956 12.02.2020 17:57:50 false simple-api.0 2020-02-12 17:57:59.193 12.02.2020 17:57:20 false simple-api.0 2020-02-12 17:57:24.763 12.02.2020 17:55:50 false simple-api.0 2020-02-12 17:55:59.177 12.02.2020 17:55:20 false simple-api.0 2020-02-12 17:55:24.743 12.02.2020 17:53:50 false sql.0 2020-02-12 17:54:54.975hier ein Neustart von der Raspberry um zu sehen ob der Abruf sich ändert :
hier ist die Aktualisierung , jede 60 sek. / 30 sek. / 60 sek.
.12.02.2020 18:19:50 false simple-api.0 2020-02-12 18:19:53.802 12.02.2020 18:19:20 false simple-api.0 2020-02-12 18:19:32.322 12.02.2020 18:18:20 false simple-api.0 2020-02-12 18:18:28.708 12.02.2020 18:17:20 false simple-api.0 2020-02-12 18:17:25.180 12.02.2020 18:15:50 false simple-api.0 2020-02-12 18:16:00.567 12.02.2020 18:14:50 false simple-api.0 2020-02-12 18:14:57.002 12.02.2020 18:13:50 false simple-api.0 2020-02-12 18:13:53.489 12.02.2020 18:13:20 false simple-api.0 2020-02-12 18:13:31.998 12.02.2020 18:12:20 false simple-api.0 2020-02-12 18:12:28.503 12.02.2020 18:11:20 false simple-api.0 2020-02-12 18:11:25.035 12.02.2020 18:09:50 false simple-api.0 2020-02-12 18:10:00.476und nochmal ein Neustart :
hier ist die Aktualisierung , 120 sek. / 60 sek. / 30 sek. / 60 sek.
12.02.2020 18:32:20 false simple-api.0 2020-02-12 18:32:28.679 12.02.2020 18:31:20 false simple-api.0 2020-02-12 18:31:25.186 12.02.2020 18:29:50 false simple-api.0 2020-02-12 18:30:00.645 12.02.2020 18:28:50 false simple-api.0 2020-02-12 18:28:57.053 12.02.2020 18:27:50 false simple-api.0 2020-02-12 18:27:53.538 12.02.2020 18:27:20 false simple-api.0 2020-02-12 18:27:32.101 12.02.2020 18:26:20 false simple-api.0 2020-02-12 18:26:28.615 12.02.2020 18:25:20 false simple-api.0 2020-02-12 18:25:25.135 12.02.2020 18:23:50 false simple-api.0 2020-02-12 18:24:00.539 12.02.2020 18:22:50 false simple-api.0 2020-02-12 18:22:57.034also verschiedene Zeiten…. :disappointed:
EDIT :
hier die weitere Laufzeit nach 18:32 Uhr@Glasfaser Danke. Ist zwar ziemlich regelmäßig, verstehen tue ich es aber nicht.
Da ich für die kumulierte Jahresregenmenge sowieso Änderungen im Bereich des netcat vornehmen muss, dürfte sich das Problem (hoffentlich) aber auch damit erledigt haben. Die Station kann dann senden wann immer sie lustig ist :)LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@crunchip Man merkt so langsam, dass ich im Trüben rumstochere.. ;)
Wahrscheinlich ist die Umstellung nur für die Uhrzeit am Display. Trotzdem müsste ich jetzt Winter-/Sommerzeit berücksichtigen, nur wie lange gibt es sie noch...
Ich werde es vom externen Trigger auf einen internen umstellen. Dann wird automatisch um 23:58 Uhr UTC addiert. Dann ist CET/CEST völlig egal. Ich muss dann nur verhindern falls bspw. zwei mal um 23:58 Uhr ein Datenpaket eintrudelt (bei 16 Sek. könnten es sogar drei sein), dass mehrmals für den Tag die Menge aufsummiert wird. Muss ich also noch den "tc" abfragen, ob ber älter als x Minuten ist...@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Umstellung nur für die Uhrzeit am Display.
Zumindest wurde der Datenpunkt Uhrzeit geändert, da ich dann eine Stunde hinterher war.
Und deshalb wahrscheinlich meine Regenmenge um 23.00...umgestiegen von Proxmox auf Unraid
-
@Glasfaser Danke. Ist zwar ziemlich regelmäßig, verstehen tue ich es aber nicht.
Da ich für die kumulierte Jahresregenmenge sowieso Änderungen im Bereich des netcat vornehmen muss, dürfte sich das Problem (hoffentlich) aber auch damit erledigt haben. Die Station kann dann senden wann immer sie lustig ist :)@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Die Station kann dann senden wann immer sie lustig ist
Wäre da jetzt noch was möglich ...??
..... im Script dann auf 16 sekunden zu bekommen bzw. eine Änderung einzubauen ?Synology 918+ 16GB - ioBroker in Docker v9 , VISO auf Trekstor Primebook C13 13,3" , Hikvision Domkameras mit Surveillance Station .. CCU RaspberryMatic in Synology VM .. Zigbee CC2538+CC2592 .. Sonoff .. KNX .. Modbus ..
-
@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Umstellung nur für die Uhrzeit am Display.
Zumindest wurde der Datenpunkt Uhrzeit geändert, da ich dann eine Stunde hinterher war.
Und deshalb wahrscheinlich meine Regenmenge um 23.00...@crunchip Dann müsstest du noch mal kontrollieren ob er jetzt immer um 0:00 Uhr UTC nullt, oder nach unserer Zeitzone um 0:00 Uhr. Aktuell addiere ich um 23:58 Uhr UTC.
LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@SBorg sagte in [Linux Shell-Skript] WLAN-Wetterstation:
Die Station kann dann senden wann immer sie lustig ist
Wäre da jetzt noch was möglich ...??
..... im Script dann auf 16 sekunden zu bekommen bzw. eine Änderung einzubauen ?@Glasfaser Das ist dann völlig egal. Sendet sie alle 16 Sekunden, hast du alle 16 Sekunden die Daten. Sendet sie alle 5 Minuten, dann hast du halt alle 5 Minuten ein Datenpaket.
Nur unter 5 Sekunden wird nicht funktionieren, da die Aufbereitung und senden an den ioB auch etwas Zeit braucht. Aber das macht die Station eh nicht, auch wären dann wohl die Batterien ratzfatz leer ;)LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@Glasfaser Das ist dann völlig egal. Sendet sie alle 16 Sekunden, hast du alle 16 Sekunden die Daten. Sendet sie alle 5 Minuten, dann hast du halt alle 5 Minuten ein Datenpaket.
Nur unter 5 Sekunden wird nicht funktionieren, da die Aufbereitung und senden an den ioB auch etwas Zeit braucht. Aber das macht die Station eh nicht, auch wären dann wohl die Batterien ratzfatz leer ;)Nochmal ... habe gerade ein großes ?
Die Station sendet das Datenpaket alle 16 Sekunden auch per nc -lv -p 9999 nachvollziebar.
In deinen Skript habe ich dann den WS_POLL auf 16 eingestellt ,
aber in " ioBroker" kommen die Daten alle 30 / 60 / 120 sekunden unterschiedlich an.Daher meine Frage ob man da noch was am Skript ändern kann !?
Synology 918+ 16GB - ioBroker in Docker v9 , VISO auf Trekstor Primebook C13 13,3" , Hikvision Domkameras mit Surveillance Station .. CCU RaspberryMatic in Synology VM .. Zigbee CC2538+CC2592 .. Sonoff .. KNX .. Modbus ..
-
@crunchip Dann müsstest du noch mal kontrollieren ob er jetzt immer um 0:00 Uhr UTC nullt, oder nach unserer Zeitzone um 0:00 Uhr. Aktuell addiere ich um 23:58 Uhr UTC.
-
Nochmal ... habe gerade ein großes ?
Die Station sendet das Datenpaket alle 16 Sekunden auch per nc -lv -p 9999 nachvollziebar.
In deinen Skript habe ich dann den WS_POLL auf 16 eingestellt ,
aber in " ioBroker" kommen die Daten alle 30 / 60 / 120 sekunden unterschiedlich an.Daher meine Frage ob man da noch was am Skript ändern kann !?
@Glasfaser Die Verzögerung kommt nicht vom Skript selbst bzw. der Verarbeitung der Daten. Vom empfangen des Datenpakets bis zum DP im ioB dauert max. 1-2 Sekunden. Das Problem ist derzeit, dass er "hört", die Station aber nix sendet, oder die Station sendet, der Rechner aber gerade nicht "zuhört"... Alle xx Sekunden treffen sich dann beide mal und die Kommunikation klappt.
Künftig "hört" er einfach immer zu, egal ob die Station was sagt oder nicht. Kommt dann ein Paket (egal ob nun alle 16 oder xxx Sekunden), ist es max. 1-2 Sekunden später in den DPs des ioB.LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@crunchip sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@SBorg geb ich dir morgen Bescheid
Keine Eile, ist noch genug zu tun :blush:
LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
@Glasfaser Die Verzögerung kommt nicht vom Skript selbst bzw. der Verarbeitung der Daten. Vom empfangen des Datenpakets bis zum DP im ioB dauert max. 1-2 Sekunden. Das Problem ist derzeit, dass er "hört", die Station aber nix sendet, oder die Station sendet, der Rechner aber gerade nicht "zuhört"... Alle xx Sekunden treffen sich dann beide mal und die Kommunikation klappt.
Künftig "hört" er einfach immer zu, egal ob die Station was sagt oder nicht. Kommt dann ein Paket (egal ob nun alle 16 oder xxx Sekunden), ist es max. 1-2 Sekunden später in den DPs des ioB. -
@crunchip sagte in [Linux Shell-Skript] WLAN-Wetterstation:
@SBorg geb ich dir morgen Bescheid
Keine Eile, ist noch genug zu tun :blush:
umgestiegen von Proxmox auf Unraid
-
@crunchip Danke, dann war die Annahme richtig, dass bis 23:59:59 Uhr UTC noch die Tagesmenge vorhanden ist und um 0:00:00 Uhr UTC genullt wird.
-
V0.1.4 Beta 1 steht auf GitHub bereit. Update wie üblich, Javascript nicht vergessen, da neuer DP.
- Änderung am netcat-Verhalten (Skript empfängt wann immer die Station etwas sendet)
- kumulierte Jahresregenmenge
Die bisherige Jahresregenmenge muss per Hand im DP eingetragen werden. Um 23:58 - 23:59 Uhr wird dann einmalig pro Tag die Tagesmenge der Jahresmenge hinzu addiert. Am DP "Regen Jahr kumuliert" sollten sonst keine Schreibzugriffe erfolgen. Wenn dessen Zeitstempel "letzte Änderung" nicht mindestens 1 Stunde alt ist, erfolgt um Mitternacht kein Übertrag der Regenmenge! Dies ist notwendig, damit nur einmal gegen Mitternacht ein Übertrag erfolgt. Sonst könnte das nächste Datenpaket bereits die Tagesmenge genullt haben, oder ich bin zu früh und addiere die Tagesmenge mehrmals auf...
LG SBorg ( SBorg auf GitHub)
Projekte: Lebensmittelwarnung.de | WLAN-Wetterstation | PimpMyStation -
V0.1.4 Beta 1 steht auf GitHub bereit. Update wie üblich, Javascript nicht vergessen, da neuer DP.
- Änderung am netcat-Verhalten (Skript empfängt wann immer die Station etwas sendet)
- kumulierte Jahresregenmenge
Die bisherige Jahresregenmenge muss per Hand im DP eingetragen werden. Um 23:58 - 23:59 Uhr wird dann einmalig pro Tag die Tagesmenge der Jahresmenge hinzu addiert. Am DP "Regen Jahr kumuliert" sollten sonst keine Schreibzugriffe erfolgen. Wenn dessen Zeitstempel "letzte Änderung" nicht mindestens 1 Stunde alt ist, erfolgt um Mitternacht kein Übertrag der Regenmenge! Dies ist notwendig, damit nur einmal gegen Mitternacht ein Übertrag erfolgt. Sonst könnte das nächste Datenpaket bereits die Tagesmenge genullt haben, oder ich bin zu früh und addiere die Tagesmenge mehrmals auf...
-
V0.1.4 Beta 1 steht auf GitHub bereit. Update wie üblich, Javascript nicht vergessen, da neuer DP.
- Änderung am netcat-Verhalten (Skript empfängt wann immer die Station etwas sendet)
- kumulierte Jahresregenmenge
Die bisherige Jahresregenmenge muss per Hand im DP eingetragen werden. Um 23:58 - 23:59 Uhr wird dann einmalig pro Tag die Tagesmenge der Jahresmenge hinzu addiert. Am DP "Regen Jahr kumuliert" sollten sonst keine Schreibzugriffe erfolgen. Wenn dessen Zeitstempel "letzte Änderung" nicht mindestens 1 Stunde alt ist, erfolgt um Mitternacht kein Übertrag der Regenmenge! Dies ist notwendig, damit nur einmal gegen Mitternacht ein Übertrag erfolgt. Sonst könnte das nächste Datenpaket bereits die Tagesmenge genullt haben, oder ich bin zu früh und addiere die Tagesmenge mehrmals auf...
Support us
868
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge