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

[G.Hawk]

@viper4iob
Ich habe jetzt alle Leerzeichen gelöscht.
Keine Veränderung

[G.Hawk]

@thomas-braun
Den habe ich garnicht benutzt.

[G.Hawk]

Deutet der Fehler nicht eher daraufhin, dass die Datei garnicht gefunden wird bzw nicht ausführbar ist?

[Thomas Braun]

@martin-0

Dann schau nach:

ls -la /home/iobroker/wetterstation.sh

[G.Hawk]

pi@raspberrypi:~ $ ls -la /home/iobroker/wetterstation.sh
-rwxr-xr-x 1 root root 15472 Nov  3 09:40 /home/iobroker/wetterstation.sh

---

Mod-Edit: Code in </> Code-Tag gepackt!

[G.Hawk]

@martin-0
Es lag an der Formatierung.

Ich habe Leerzeilen eingefügt zwischen den Befehlen. Jetzt geht es.

[viper4iob]

@martin-0
Das klingt dann danach, dass die Zeilenumbrüche nicht gepasst haben.
Linux nutzt LF und Windows CRLF und wenn man das irgendwie von Windows rüber holt, hat man evtl. die falschen.
Da gibt es dann z.B. das Kommando dos2unix, um das umzuwandeln.
Und wenn man die Zeilenumbrüche he dem Editor unter Linux wieder einfügt, nimmt er natürlich LF
Du hast also vorhin beim Löschen der Leerzeilen wahrscheinlich die falschen gelöscht und dann durchs einfügen, die richtigen hinzugefügt.

[Thomas Braun]

@martin-0

Die Datei in /home/iobroker sollte aber NIE dem root gehören.

[G.Hawk]

@thomas-braun
Ich habe alles mögliche umgestellt.
Warum denn nicht?

[Thomas Braun]

@martin-0
Weil das das /home des iobrokers ist. Und nicht vom root. Der wohnt unter /root.

[viper4iob]

@martin-0
Kannst du mal das machen :
cat -e /etc/systemd/system/wetterstation.service

Der sollte den Inhalt der Datei mit Zeilenumbrüchen darstellen. Ich hoffe auch CRLF, falls vorhanden.
Was kommt da raus?
Es geht zwar jetzt, aber diese Leerzeilen gehören da eigentlich nicht hin. Evtl. hast du jetzt beide Typen drin.

EDIT
Er müsste $ für LF anzeigen, was richtig wäre.
Und ^M$ für CRLF. Die sollten da nicht auftauchen.

[Thomas Braun]

@martin-0

sudo chown iobroker:iobroker /home/iobroker/wetterstation.sh

[viper4iob]

Zum Thema Dateirechten und Besitzerschaft vom Skript:
Im Prinzip gebe ich @Martin-0 recht. Wenn man das Skript im Home vom iobroker betreibt, sollte es auch iobroker gehören.
Aus Sicherheitssicht spielt es aber keine große Rolle, denn sobald das Skript als systemd Service gestartet wird, läuft es unter root. Kann man beispielsweise mit ps -ef | grep wetterstation kontrollieren.
Und das Risiko ist denke ich deutlich höher, falls eben jemand das Github Repository manipuliert und man sich diese Änderungen dann installiert.

Wichtig wäre also meiner Meinung nach den Service unter einem anderen User als root ausführen zu lassen. Das Skript braucht soweit ich das aktuell feststellen konnte, für das normale Ausführen keine root-Rechte, es führt netcat aus und solange der Port über 1024 ist, braucht das keine root Rechte. Und dann kommuniziert es mit iobroker und die InfluxDB über deren Schnittstellen, was ebenfalls keine root Rechte benötigt.
Um den Service als anderer User zu starten muss man im Service File im Abschnitt [Service] die Argumente User und Group hinzufügen und da dann beispielsweise den iobroker angeben.
Ich hab es aktuell unter meinem eigenen User laufen.
Streng genommen sind beide User nicht optimal und man müsste einen komplett neuen User nur für das Skript anlegen, der sich auch nicht interaktiv anmelden kann und darüber dann den Dienst laufen lassen, aber das war mir dann auch zu viel des Guten.
Unter meinem User funktioniert es auf alle Fälle.
Über den iobroker User habe ich es noch nicht getestet. Der iobroker user wäre vielleicht aktuell sogar die bessere Wahl, weil der sich wahrscheinlich nicht interaktiv anmelden kann, also nur ein System User ist. Nur weiß man nie, ob sich da mit irgendeinem Update mal wieder was ändern könnte. Bis vor einiger Zeit lief der iobroker auch nicht unter eigenem User, das wurde dann irgendwann mal angepasst.

@SBorg
Das wäre evtl. nochmal ein Punkt, worüber man für den Install Guide und der Service File Definition nachdenken könnte. Vielleicht auch einfach nur als Hinweis und man kann dann selbst entscheiden.

[SBorg]

@viper4iob Solange bspw. die "sh" root:root gehört und der User also das Ganze als root durchführt (weil es ja einfacher ist und man nicht dauernd ein Passwort eingeben muss, oder dauernd ein sudo nutzen muss... :man-facepalming: ) sehe ich es noch als "geringeres Übel" an. 99% der User werden auch einfach die "sh"s ausführen ohne vorher mal rein zu sehen. Wozu auch, verstehen eh nur die wenigsten und bei Windows sehe ich in der setup.exe eh nicht was am/im System passiert. Ihnen ist aber nicht bewusst, dass, wenn sie es als "root" ausführen, ich die volle Kontrolle über ihr Systems erlange. Wenn ich dies denn wollte, und nein liebe Mitleser, da brauche ich nicht mal was zu hacken.
Diese Gefahr besteht natürlich auch wenn man meinen GitHub-Account hackt. Deswegen announce ich auch neue Betas und Releases immer hier. So müsste er auch meinen Foren-Account hacken. Allerdings wird da nicht jeder darauf achten, und diejenigen die per Suche auf das GitHub-Repository stoßen sowieso nicht.

Trotzdem könnte man es natürlich auch einfach als User-Service laufen lassen, gäbe es nicht wieder eine Ausnahme mit Protokoll #9. Dies läuft explizit (da es ein offizieller Web-Server sein muss) nur auf Port 80, sonst würde ich einfach keine Ports <=1024 mehr zulassen und könnte mich damit nur Userrechten zuwenden.

Die Idee mit einem extra unprivilegierten User hat aber was (iobroker mag ich aus den von dir schon genannten Gründen nicht). Dann müsste nur der Protokoll #9-Nutzer den Service halt mit root-Rechten laufen lassen.

---

Nutzt denn wer einen Port <=1024? Wenn ja, warum (außer Protokoll #9-Nutzer ;) ) ? Es gibt ~64.5k andere Ports :)

[viper4iob]

Ich habe mal eine Frage Richtung Best Practice für das Thema iobroker, InfluxDB, Grafana.
Und zwar gibt es Datenpunkte, bei denen nur der aktuelle Wert eine Rolle spielt, wie z.B. Letzte_Regenmenge. Aus Sicht iobroker macht es keinen Sinn diese als Historie in der InfluxDB mitzuschreiben.
Damit der Wert aber in Grafana angezeigt werden kann, muss man es doch tun.
Da sich der Wert nicht so oft ändert, lasse ich nur Änderungen in die DB schreiben, man muss ja nicht unnötig Daten schreiben, dachte ich.
Allerdings ist das nun für Grafana ein ziemliches Problem, denn Grafana zeigt Werte aus einem bestimmten Zeitraum an. Also beispielsweise die letzten 24 Stunden. Für einen Graphen ist das natürlich sinnvoll, aber oft will man ja nur den letzten aktuellen Wert anzeigen.
Und da kommen wir zum Problem: Wenn innerhalb dieses Zeitraums kein Wert in die InfluxDB geschrieben wurde, zeigt er gar nichts an, also NA bzw. No Data.
Muss ich jetzt wirklich im iobroker bei der Historie eines solchen Datenpunkts einstellen, dass der in festen Zeitabständen geschrieben wird, damit das in Grafana angezeigt wird?
Wenn man das auf die Spitze treibt und ich in Grafana mal den Zeitraum auf 5 min stellen will, dann müsste man im iobroker einstellen, dass im Endeffekt alle 5 min der gleiche Wert geschrieben wird, nur damit es in Grafana angezeigt wird.
Das macht irgendwie keinen Sinn.
Was ist hier also sinnvoll?

[tege0]

@laplaceii Hallo, bin auch am überlegen mir die BRESSER WLAN Comfort Wettercenter mit 7-in-1 zuzulegen. Konntest du deine Station die ja ein Clone dazu ist integrieren? Finde das Stationsdisplay eigentlich ganz schick. Wie sind deine Erfahrungen?

Zudem hab ich noch eine andere frage, ich würde gerne eine Onedrop Meldung bekommen. Welchen Sensoren kann ich hierfür einbinden?

[LaplaceII]

@tege0 Hallo, ich habe auch tatsächlich die Bresser Station (ist baugleich mit der Explore Scientific, da Bresser die Station nur vertreibt, steht sogar Explore Scientifc drauf). Ich habe mich um die Integration, trotz angebotener Unterstützung nicht wirklich kümmern können. Über den klassischen Weg die WS View app zu nutzen geht es nicht: Wenn ich unter Device list die IP der Station angebe passiert leider nichts. Ggf. hat hier jemand schon Erfahrungen....
Den in der Installationsanleitung gezeigten Screen kann ich bei mir nicht aufrufen

[Langer]

@sborg

Hallo,

anbei ein Screenshot einer Darstellung von Deinem Wetterstatistik Programm. Von Liv-in-sky habe ich mir die Grundlagen geholt.

Nun meine Fragen:

1. Könnte man zB. am 01.01.2022 eine komplette Monatsstruktur anlegen, also 01 - 12 und mit jeweils mit einem json füllen der nur "0" als Wert enthält?

{
"Tiefstwert":0,
"Hoechstwert":0,
"Temp_Durchschnitt":0,
"Max_Windboe":0,
"Max_Regenmenge":0,
"Regenmenge_Monat":0,
"warme_Tage":0,
"Sommertage":0,
"heisse_Tage":0,
"Frost_Tage":0,
"kalte_Tage":0,
"Eistage":0,
"sehr_kalte_Tage":0,
"Trockenperiode":0
}

2. Wenn Du um 01:03 Deine Statistik erstellst, auch für den laufenden Monat einen json erstellst bzw. Aktualisierst?

{
"Tiefstwert":-3.5,
"Hoechstwert":10.61,
"Temp_Durchschnitt":3.91,
"Max_Windboe":21.88,
"Max_Regenmenge":21.3,
"Regenmenge_Monat":51.5,
"warme_Tage":0,
"Sommertage":0,
"heisse_Tage":0,
"Frost_Tage":5,
"kalte_Tage":7,
"Eistage":0,
"sehr_kalte_Tage":0,
"Trockenperiode":0
}

3. Das gleiche für das laufende Jahr?

4. Das gleiche für die Rekordwerte?

Ich hoffe ich habe mich einigermaßen verständlich ausgedrückt?

Über die Darstellung kann man streiten, aber es ist erst der Anfang!!

Vielen Dank im voraus

MfG
Wastl

[SBorg]

@viper4iob IMHO am einfachsten die "Gruppierung" weg lassen, dann ist die Abfrage von Grafana nach einem Zeitbereich in Influx auch weg. Trotzdem lasse ich alle 12h mal den Wert schreiben. Sind dann max. (unnötige) 730 Datenpunkte in der Influx, was aber nur paar kB ausmacht.
Man kann natürlich auch innerhalb der Serie(n) zB. auf 14 Tage beschränken mittels einer Retention Policy. Dann wird immer alles älter als 14 Tage gedroppt. Aktuell wird nach einem Jahr gelöscht (sofern man im Influx-Adapter nichts anderes eingestellt hat).

[SBorg]

@tege0 / @laplaceii Wenn die Station keinen eigenen Wetterserver zulässt, bleibt nur der Umweg per DNS-Server. Hier werden die Daten die normalerweise an WU geschickt werden auf einen heimischen Rechner umgeleitet, auf dem dann das Skript läuft. Leider ist man dann auf das WU-Protokoll beschränkt: weniger Funktionen u. weniger Sensoren.
Wenn man bspw. schon PiHole nutzt braucht man nur einen zusätzlichen Eintrag tätigen, sonst muss man zB. dnsmasq installieren und dort konfigurieren...

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

Finde das Stationsdisplay eigentlich ganz schick

Bei uns schaut da kaum einer drauf. Ich habe es halt aufgestellt weil es dabei war ;)
Die Bresser hat so keinen besseren Funktionsumfang. Wenn es nur rein um das Display geht, solltest du ev. das Gateway mit Wettermast in Betracht ziehen (da kannst du dann auch später/gleich weitere Sensoren hinzufügen). Als Anzeige nimmst du dann ein kleines Tablett oder Monitor mit bspw. einem alten Pi und lässt dort eine ioB-View drauf laufen. Da kannst du dir nicht nur das Aussehen nach belieben gestalten, sondern auch weitere Werte anzeigen lassen die das Display nicht kann. Sogar Touch ist dann möglich ;)