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

[SBorg]

@skokarl :grinning:

Leider verheißt Freitag der 13. nichts gutes :(
Ich muss euch leider mitteilen, dass die Arbeiten an der V0.1.4 mit sofortiger Wirkung eingestellt sind und es diese Version nicht geben wird...

Erstmal sacken lassen und in 5 Minuten weiter lesen...

SBorg proudly presents V1.0.0 steht auf GitHub bereit :innocent:
Es ist zwar kein offizielles release (bisher) aber auch weit über eine Beta hinaus. Kumulierte Regenmenge funktioniert nun auch, dazu noch einen Fehler in der "Kommunikationsunit" behoben. Pauschal kann man nun alle 16 Sekunden (schneller sendet die Station nicht) ein Datenpaket empfangen. Einen Wermutstropfen hat es allerdings. Obwohl meine Signalstärke und sonst alles Tipp-Topp sind, kommen von 10 gesendeten Paketen nur ~7-8 an. Warum die Station stellenweise einfach mal ein Paket überspringt konnte ich nicht eruieren. Sie sendet im eingestellten 16 Sekundentakt, dann überspringt sie ohne ersichtliches Muster mal ein Paket und sendet dann 16 Sekunden später wieder korrekt eins?!?
Daran kann ich leider nichts ändern, denn wenn das Display schon nichts sendet, habe ich auch nichts zum auswerten...

Warum Abschied von der V0.1.4 und hin zur V1.0.0?
Zum einen weil die Version dann Stand Heute alles hat was möglich/gewünscht wurde und (hoffentlich) fehlerfrei läuft. Zum anderen ich eine maßgebliche Änderung eingeführt habe. Die wetterstation.conf ist nun wirklich nur eine Konfigurationsdatei. Wenn hier nichts neues hinzukommt an Parametern, genügt es dann einfach nur die "sh" und/oder "sub" auszutauschen. Womit auch ersichtlich ist, dass mit der V1.0.0 nichts zu Ende sein muss ;)

Zum Update also sh, sub und conf ersetzen (js ist unverändert zur V0.1.4, beim Update von V0.1.3 auf V1.0.0 muss aber die js ebenfalls ersetzt und ausgeführt werden).

Freue mich auf euer Feedback und da das Wetter endlich mal passte:

Da ich keinen kurzen Mast mit geringer Ausladung fand, wurden es einfach zwei Rohrschellen mit Stockschrauben, ein imprägnierter Holzstab, der in dem kurzen beigelegten Rohr steckt und mittels einer Schraube gegen verdrehen gesichert wurde. So komme ich ohne Leiter an den Regentrichter und kann so auch die Batterien wechseln :sunglasses:
...ein letztes mal Danke dafür. Ich weiß nicht wie viel Zeit ich verbrannt habe bzw. noch verbrannt hätte, um die Fehler zu finden. Auch wenn gut 90% der Entwicklung nur aus dem Kopf heraus stattfand, muss ich dennoch gestehen, es ist was ganz anderes "live" daran zu arbeiten als nur zu simulieren.

[crunchip]

@SBorg Schreck lass nach:blush: und freu mich zu lesen, das es nun voran geht:+1:
Für deine letztens ausführliche technische Erklärung nochmals Danke, wollte eigentlich daraufhin auch antworten, nachdem ich mir 3 Tage lang den Kopf zerbrach, wie man das am besten lösen könnte, mit der Jahresregenmenge..Glaub, hatte viermal nen riesen Text geschrieben und doch immer wieder gelöscht, da meine Idee/Gedanken, es richtig umzusetzen, nicht zu Ende gedacht waren😆
Werde die neue Version dann heute gleich mal testen.

Edit: was ich noch fragen wollte, (hatte ich auch schon in der Vorherigen Version)
javascript.0.Wetterstation._Kommunikationsfehler bleibt auf true, sollte das nicht auf false wechseln?

[SBorg]

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

Schreck lass nach

Wären wir ~2.5 Wochen weiter, hätte ich es ev. sogar mal paar Stunden so im Raum stehen lassen... :relieved:
Ich habe es bereits gestern umgesetzt und heute Nacht selbst probiert. Eigentlich ist es ziemlich easy, wenn man es halt tatsächlich sieht und es sich nicht ausdenken muss wie es ev. ist.
Das Grundkonzept ist noch geblieben, nur die Parameter haben sich etwas geändert. Tatsächlich sucht sich das Display per NTP-Server immer die aktuelle Zeit. Dadurch brauche ich keine großartigen Zeitdifferenzen einkalkulieren oder auf Sommer-/Winterzeit zu achten. 0:00 Uhr ist 0:00 Uhr + da setzt er die Tagesmenge auf 0. Also frage ich ähnlich deinem Blockly ab 23:58:00 - 23:59:59 ob der Zeitstempel LC von der "kumulierten Regenmenge" älter als eine Stunde ist.
true: (es wurde also noch nichts aufaddiert), hole alten Wert, addiere aktuellen Tageswert hinzu, schreibe neuen Jahreswert (+damit erhält der LC den aktuellen Zeitstempel = ist beim nächsten Datenpaket eben keine Stunde alt)
false: mache nix (der Tageswert wurde für heute schon aufaddiert)

Das hat halt den Vorteil, dass ich je nach eingestelltem Zeitintervall des Users nicht auf ein Datenpaket "hoffen" muss, sondern einfach mehr Zeit habe eines zu bekommen. Bei 16 Sekunden Intervall und 2 Minuten Dauer wären das 7-8 Pakete, bei 30 Sekunden immer noch 3-4 Pakete und bei 60 Sekunden zumindest noch 1-2 Pakete. Da wird schon ein gültiges kommen/dabei sein.
Ich hätte natürlich auch einfach stur um 23:58 Uhr den Datenpunkt "Regen_Tag" auslesen können und einmalig einfach zum Jahreswert hinzu addieren können. Das wäre der Notfallplan gewesen, da ich so keinen Programmierfehler mehr sah.

...und gerade zu deinem EDIT: das ist dem Kommunikationsfehler geschuldet, denn da gingen tatsächlich öfters Datenpakete flöten ;)
Ist jetzt aber gefixt und habe ich auch in Grafana eingebaut:

[crunchip]

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

Wären wir ~2.5 Wochen weiter

Du Schlitzohr:blush:

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

gingen tatsächlich öfters Datenpakete

das bleibt aber immer auf true und den Wert von

• Zeitstempel
• letzte Änderung
  verstehe ich nicht, hatte ja vorhin(ca. 16Uhr) frisch die neue Version installiert und Iobroker neu gestartet

übrigens, wie bekommst du das in Grafana so hin, ich logge zwar den Datenpunkt mit, aber ich bekomm keine Zeichen rein.
hatte es mit single stat und Value Mappings probiert

[SBorg]

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

Du Schlitzohr

:grin: :innocent:
Ev. hast du das Skript 2x laufen? Beim starten sollte er es immer auf false setzen. Macht er auch und funktioniert wie es soll:

Mal sehen ob noch jemand selbiges Problem hat.

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

hatte es mit single stat und Value Mappings probiert

Damit habe ich es auch realisiert, nur habe ich per "alias" einen Datenpunkt erzeugt und true/false auf 1/0 umgesetzt.
Wetterstation.json

[crunchip]

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

Macht er auch und funktioniert wie es soll

bei mir nicht, habe den Datenpunkt ja geloggt
oberhalb der roten Markierung das alte script,
ab der roten Markierung läuft das neue script,
ab der blauen, hab ich den den Wert manuell auf false gesetzt.

man sieht auch, das ab Uhrzeit18:34:47.848 kein simple-api mehr geschrieben wird, nur noch die automatischen alle 1800 sec

[Ein ehemaliger Benutzer]

@crunchip @SBorg bei mir steht der Kommunikationsfehler auch auf true, warum auch immer... ich log den Wert mal...

[crunchip]

ich hab den Datenpunkt mal gelöscht und neu angelegt, immer noch das gleiche.
Danach habe ich mal das script gestoppt und wieder gestartet, jetzt bekomm ich nicht mal mehr Werte.
Iobroker neu gestartet, Wetterstation kurz vom Strom genommen, keine Werte.

Einzigte was heute geändert wurde, das Script auf v1.0 und ein Update der App war heute

Edit:
in Putty eingegeben

• ./wetterstation.sh --debug keine Werte
• pkill -9 wetterstation.*
• nc -lv -p 55555 Werte kamen
• ./wetterstation.sh --debug keine Werte

in der Proxmox Konsole, iobroker VM

• ./wetterstation.sh --debug no connection fortlaufend
  ioBroker neu gestartet, läuft nun wieder

geloggter Datenpunkt zeigt, genau einmal zum Scriptstart ein false springt dann um auf true

• Liste aktualisiert,
  einmal wird geschaltet um 2020-03-14 00:02:01.336

false 	true 	simple-api.0 	2020-03-13 22:32:09.799 	
true 	true 	simple-api.0 	2020-03-13 22:32:14.947 	
true 	true 	influxdb.0 	2020-03-13 22:35:22.514
true 	true 	simple-api.0 	2020-03-13 23:05:22.521
true 	true 	simple-api.0 	2020-03-13 23:35:22.522 	
false 	true 	simple-api.0 	2020-03-14 00:02:01.336 	
true 	true 	simple-api.0 	2020-03-14 00:02:06.555 	
true 	true 	simple-api.0 	2020-03-14 00:32:06.558 	
true 	true 	simple-api.0 	2020-03-14 01:02:06.560 	
true 	true 	simple-api.0 	2020-03-14 01:32:06.561
...

[Nashra]

Moin, habe genau das gleiche Problem wie @crunchip . Gewechselt auf 0.1.4 und es läuft erstmal wieder.

[SBorg]

Vorweg: etwas ist bei euch nicht so wie es sein sollte

Aber es liegt wohl auch ein Fehler im Gedankengang vor wie der DP "Kommunikationsfehler" genau funktioniert:

• beim Start des Skriptes wird er einmalig auf false gesetzt
• wenn alles korrekt läuft tut sich jetzt gar nichts mehr, er wird auch nicht aktualisiert (*)
• konnten 5 Datenpakete(**) nicht empfangen werden, wird er einmalig auf true gesetzt
• mehr passiert da nicht

(*)hier liegt wohl das Missverständnis. Aber warum sollte ich diesen alle xx Sekunden aktualisieren? Müllt nur das System unnötig zu, um dann was genau zu machen (außer mitzuteilen "habe keinen Fehler" ;) )? Schließlich ruft doch auch keiner jeden Kilometer in seiner Autowerkstatt an, nur um mitzuteilen, dass das Auto noch fährt. Ich melde mich erst wenn was nicht funktioniert... (oder auch nicht, bin im ADAC :innocent: ) Genau so verhält es sich hier: keine news sind good news. Ich melde mich erst mit true wenn ein Fehler auftritt. So kann ich auch mit wenig Daten in die influx loggen: nur auf Änderung + alle 12h mal einen Wert schreiben (sonst läuft ggf. Grafana ins Leere mit "No Data")
(**) egal wann sie auftreten, es gibt keinen Unterschied ob 5x hintereinander, oder insgesamt 5 Fehler in x Stunden. Da bspw. um 0:02 Uhr per cronjob das Skript beendet wird, wird zu diesem Zeitpunkt auch der Zähler wieder auf 0 gesetzt. So führen gelegentliche Fehler nicht gleich zu einer Anzeige. Erst "schwere" Fehler wie zu geringe Empfangsleistung, leere Batterien etc. führen dann zu einer Fehleranzeige.

Sieht dann bspw. so aus (als "alias" geloggt wg. Anzeige in Grafana):

Deswegen wäre

false 	true 	simple-api.0 	2020-03-14 00:02:01.336 	

völlig Ok, was aber nicht sein darf ist der 5 Sekunden später auftretende:

true 	true 	simple-api.0 	2020-03-14 00:02:06.555 	

So schnell ist das Skript nicht. Es muss mindestens 16 Sekunden warten (genau genommen sogar 2* 16 + 6 Sekunden). Das wäre aber ein Fehler. Es kann also frühstens nach (2*16+6)*5 = 190 Sekunden auftreten.
Fallen mir nur zwei Szenarien ein.

1. nc (ev. falsche Version, in der V1.0.0 werden zwei neue Parameter benutzt)
2. das Skript läuft mehrmals

Leider hat der "nc" keine Versionsinfo. Kann das euer nc:

Sicherheitshalber das Skript mittels pkill -9 wetterstation.sh beenden. Bei ".*" ist mir aufgefallen, dass es nicht immer beendet wird. Nochmals mittels ps -aux | grep wetterstation.sh prüfen, dass es wirklich nicht mehr läuft!
Das würde genau zu @crunchip Fehlerbild passen. Erst keine Werte, da das Skript schon auf dem Port läuft, dann bekommt die 2. Instanz keinerlei Daten.

btw: Jahresregenmenge hat wieder funktioniert, scheint also zu funktionieren :sunglasses:

[crunchip]

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

das Skript läuft mehrmals

ist doch normalerweise gar nicht möglich, da ich die Maschine(VM) neu gestartet habe. ich habe auch nur eine Version installiert. dementsprechend würde ich sagen,
2. fällt da flach, muss also etwas anderes sein

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

Kann das euer nc:

wie macht man das?

[SBorg]

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

da ich die Maschine(VM) neu gestartet habe

= bei dir iobroker? Wenn du also schreibst "iobroker neu gestartet" ist dies nicht der/unser iobroker sondern deine VM :)
Schau mal was bei gestopptem Skript mittels ./wetterstation.sh --data kommt. Ist dies ein Datenpaket oder irgendeine Meldung?

[crunchip]

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

nicht der/unser iobroker sondern deine VM

ja die VM neu gestartet, ist folglich iobroker selbst dann ja auch neugestartet

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

Schau mal was bei gestopptem Skrip

mom, teste ich

root@IoBroker:/home/iobroker# ./wetterstation.sh --data


Warte maximal 66 Sekunden auf Datenpaket der Wetterstation...

listening on [any] 55555 ...
no connection : Connection timed out
root@IoBroker:/home/iobroker#

anschliessend nun wieder gestartet, jetzt hab ich wieder das Problem

root@IoBroker:/home/iobroker# ./wetterstation.sh
listening on [any] 55555 ...
Warning: forward host lookup failed for ESP_9C8A47.local: Unknown host
connect to [10.1.1.10] from ESP_9C8A47.local [10.1.1.206] 24230
listening on [any] 55555 ...
no connection : Connection timed out
listening on [any] 55555 ...
no connection : Connection timed out
listening on [any] 55555 ...
no connection : Connection timed out
listening on [any] 55555 ...
no connection : Connection timed out
listening on [any] 55555 ...
no connection : Connection timed out
listening on [any] 55555 ...
no connection : Connection timed out
listening on [any] 55555 ...
no connection : Connection timed out
listening on [any] 55555 ...
Warning: forward host lookup failed for ESP_9C8A47.local: Unknown host
connect to [10.1.1.10] from ESP_9C8A47.local [10.1.1.206] 31842
listening on [any] 55555 ...
no connection : Connection timed out
listening on [any] 55555 ...
no connection : Connection timed out
listening on [any] 55555 ...
no connection : Connection timed out
listening on [any] 55555 ...
Warning: forward host lookup failed for ESP_9C8A47.local: Unknown host
connect to [10.1.1.10] from ESP_9C8A47.local [10.1.1.206] 5617
listening on [any] 55555 ...
no connection : Connection timed out
listening on [any] 55555 ...
no connection : Connection timed out
listening on [any] 55555 ...
no connection : Connection timed out
listening on [any] 55555 ...
no connection : Connection timed out
listening on [any] 55555 ...
no connection : Connection timed out
listening on [any] 55555 ...
no connection : Connection timed out
listening on [any] 55555 ...
no connection : Connection timed out
listening on [any] 55555 ...
no connection : Connection timed out
listening on [any] 55555 ...
no connection : Connection timed out
listening on [any] 55555 ...
no connection : Connection timed out
listening on [any] 55555 ...
no connection : Connection timed out
listening on [any] 55555 ...
no connection : Connection timed out

die Datenpunkte im Iobroker werden aber aktualisiert und läuft weiterhin!!?

Edit, scheinbar alles verzögernd , letzte Messung 13.43.29 und wird nicht mehr aktualisiert, bekomm es auch nicht wieder zum laufen, selbe Problem wie gestern.

[crunchip]

@SBorg also nochmal von vorn

• VM neu gestartet
  *Ausgabe grep

root@IoBroker:~# ps -aux | grep wetterstation.sh
root       695  0.4  0.0  11548  3344 ?        S    13:53   0:00 /bin/bash /home/iobroker/wetterstation.sh
root      2297  0.0  0.0  11548  2092 ?        S    13:55   0:00 /bin/bash /home/iobroker/wetterstation.sh
root      2302  0.0  0.0  12780  1016 pts/0    S+   13:55   0:00 grep wetterstation.sh

Werte für javascript.0.Wetterstation._Kommunikationsfehler (mein Abfrageintervall ist 30 sec)

false 	true 	simple-api.0 	2020-03-14 13:52:26.944 	
true 	true 	simple-api.0 	2020-03-14 13:52:32.131

nur so am Rande gefragt, im log hab ich gerade gesehen(durch den Neustart)

host.IoBroker	2020-03-14 13:57:18.088	error	Caught by controller[0]: at process._tickCallback (internal/process/next_tick.js:68:7)
host.IoBroker	2020-03-14 13:57:18.087	error	Caught by controller[0]: at promise.then (/opt/iobroker/node_modules/standard-as-callback/built/index.js:19:49)
host.IoBroker	2020-03-14 13:57:18.087	error	Caught by controller[0]: at tryCatcher (/opt/iobroker/node_modules/standard-as-callback/built/utils.js:11:23)
host.IoBroker	2020-03-14 13:57:18.087	error	Caught by controller[0]: at (anonymous function).(anonymous function) (/opt/iobroker/node_modules/iobroker.objects-redis/index.js:17:107068)
host.IoBroker	2020-03-14 13:57:18.086	error	Caught by controller[0]: TypeError: Cannot read property 'common' of null
simple-api.0	2020-03-14 13:57:17.534	info	(3520) Terminated (NO_ERROR): Without reason
simple-api.0	2020-03-14 13:57:17.533	info	(3520) terminating
simple-api.0	2020-03-14 13:57:17.510	info	(3520) terminating http server on port 8087
simple-api.0	2020-03-14 13:57:17.508	error	at process._tickCallback (internal/process/next_tick.js:68:7)
simple-api.0	2020-03-14 13:57:17.508	error	at promise.then (/opt/iobroker/node_modules/standard-as-callback/built/index.js:19:49)
simple-api.0	2020-03-14 13:57:17.508	error	at tryCatcher (/opt/iobroker/node_modules/standard-as-callback/built/utils.js:11:23)
simple-api.0	2020-03-14 13:57:17.508	error	at (anonymous function).(anonymous function) (/opt/iobroker/node_modules/iobroker.objects-redis/index.js:17:107068)
simple-api.0	2020-03-14 13:57:17.508	error	(3520) TypeError: Cannot read property 'common' of null
simple-api.0	2020-03-14 13:57:17.506	error	(3520) uncaught exception: Cannot read property 'common' of null

[SBorg]

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

root@IoBroker:~# ps -aux | grep wetterstation.sh
root 695 0.4 0.0 11548 3344 ? S 13:53 0:00 /bin/bash /home/iobroker/wetterstation.sh
root 2297 0.0 0.0 11548 2092 ? S 13:55 0:00 /bin/bash /home/iobroker/wetterstation.sh
root 2302 0.0 0.0 12780 1016 pts/0 S+ 13:55 0:00 grep wetterstation.sh

Jepp, Skript läuft doppelt. Daher bekommst du gelegentlich Werte, Direkttests funktionieren deswegen auch nicht (der Port ist durch die 1. Instanz bereits belegt)
Die "13:53 Uhr" dürfte der Autostart vom Reboot sein, aber wo die "13:55 Uhr" herkommt? Oder hattest du da zwischenzeitlich das Skript manuell gestartet? Oder hast du es ev. doppelt in der crontab stehen?
Das erklärt dann natürlich auch warum der "Kommunikationsfehler" so schnell kommt. Da werkelt die eine Instanz noch, wird von der 2. blockiert und meckert dann natürlich zu Recht ;)

und wenn dann sich noch mit

simple-api.0	2020-03-14 13:57:17.510	info	(3520) terminating http server on port 8087

der Simple-API verabschiedet geht sowieso auch im ioB nüscht mehr.

[crunchip]

@SBorg wie kann bitte das script doppelt laufen?
es war lediglich ein Neustart der VM,(kein manuelles starten des scripts)
anschliessend habe ich ps -aux | grep wetterstation.sh aufgerufen,
mit dem Ergebnis von oben.

ein crontab ist nur einmal eingetragen

@reboot /home/iobroker/wetterstation.sh &
2 0 * * * pkill -9 wetterstation.* && /home/iobroker/wetterstation.sh &

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

aber wo die "13:55 Uhr" herkommt?

die Uhrzeit ändert sich, wenn ich den Befehl erneut ausführe, also immer die aktuelle Uhrzeit beim Befehlsaufruf

[Ein ehemaliger Benutzer]

@crunchip bei welchem User hast du den Cron eingetragen? Jeder user hat seinen eigenen Cron.. nicht vergessen.. da hab ich mir auch schon ein paar Eigentore geschossen, weil ein Cron beim falschen user drin war...

[Ein ehemaliger Benutzer]

@crunchip also zum nachvollziehen, ein "sudo crontab -e " ist eine andere also einfach nur crontab -e :-)

[crunchip]

@ilovegym ich bin mit root drauf

[crunchip]

@ilovegym aber danke für den Hinweis, hab mal mit sudo eingegeben
ist ein anderes temp/crontab.xxxxx
also bewusst hatte ich kein sudo eingegeben, ist dann wohl scheinbar zu Anfangszeiten durch copy and past passiert, das nochmal ein zweiter crontab gesetzt wurde.