Hallo zusammen,
Habe Werte von Sensoren in einer Datenbank (mysql), diese Werte möchte ich in fhem 'weiterverarbeiten'.
z.B. Temperatur anzeigen
dblog habe ich eingerichtet und funktioniert.
Beispiele dazu habe ich zwar hier im Forum gefunden (z.B. die Werte per Script einlesen),
aber ich habe hier eine Verständnisfrage, wieso kann ich die Werte nicht einfach per SQL
(z.B. Trigger) in die history bzw current Tabelle eintragen? Und dann einen 'pseudo' sensor anlegen,
der die Werte wie ein realer Sensor anzeigt?
Habe dazu keinen Ansatz im Forum gefunden, bzw. vielleicht auch nicht die richtige Formulierung verwendet?
Gibt es da etwas? Wenn ja, wie lege ich so einen Sensor in fhem 'richtig' an.
PS: wer es bis jetzt noch nicht ahnte, bin absoluter Anfänger was fhem betrifft. ;D
Die Frage was Du mit "weiterverarbeiten" machen willst?
Wenn Du sie nur "anzeigen" willst sollte das möglich sein, wenn die Daten in der normalen Dblog-tabelle korrekt drinstehen. Aber wozu?
Wenn Du die Daten wie bei einem FHEM-Device (als Readingwerte) anzeigen willst, dann bist Du meiner Meinung nach auf dem falschen Weg. in FHEM ist der Log (File oder DB) das Ergebnis von Readings (eigentlich events) und die Werte werden nicht AUS der DB am Device angeziegt sondern vom entpsrechenden Sensor an FHEM übermittelt und dann im device abgelegt.
Also wenn Du einen Sensor hast, den Du in FHEM anzeigen willst, wäre der normale Weg jedesmal wenn der Wert sich ändert die Daten in FHEM in den device zu übernehmen. Dazu gibt es unglaublich viele Protokolle, Module, Systeme, etc
Auch für handgebaute devices
Hi,
was für Sensoren sind das denn?
Gruß,
Thorsten
Also wenn ich das richtig interpretiere ist das eine extern gefütterte DB? Hat die denn die korrekte DbLog-Struktur? Wenn nicht hilft es, einen View von den Daten zu bauen, damit DbLog Freude damit hat. Dann muss man nur sicherstellen, das die zugehörige DbLog-Definition nichts schreiben (loggen) will.
Zum Zugriff auf die Daten gibt es DbRep (http://fhem.fritz.box:8083/fhem/docs/commandref_DE.html#DbRep) oder zur Darstellung von Verläufen eben SVG (http://fhem.fritz.box:8083/fhem/docs/commandref_DE.html#SVG%5BSVG%5B/url).
Ich versuche mich auch gerade daran, jedoch bereitet mir mein View noch Kopfzerbrechen :(
externe Grüße
Niels
Sensoren sind zum einen MobileAlerts Temp-Sensoren, die per Python-Script von der Website abgerufen werden,
die Ergebnisse werden in eine eigene Tabelle (externer MySQL-Server) gespeichert. Dort werden sie weiterverwendet (Berichte etc.)
Andere Sensoren sind Eigenbauten und werden per Script ebenfalls in MySql gespeichert. Ist einfacher, da die nur Werte
liefern und nicht - in sich - steuerbar sind.
Per Trigger kann ich die Daten in dblog-Tabellen einfügen (im richtigen Format).
View ist da wenig hilfreich, da ich schon das Log weiterfühen möchte, also damit in der fhem-welt bleibe.
Das Weiterverarbeiten in fhem stelle ich mirr so vor:
a) Werte anzeigen (Temp Aquarium 18.3 C)
b) Werteverlauf anzeigen (Tempkurve pro Tag)
c) errechnete Werte anzeigen (Tagesmax, Tagesmin, Durchschnitt)
d) Aktionen starten (wenn über 19 C, Lüftung einschalten (Schaltakuator Homematic)
DBRep schaue ich mir mal genauer an :D
Zitat von: germansleeper am 29 April 2017, 17:08:16d) Aktionen starten (wenn über 19 C, Lüftung einschalten (Schaltakuator Homematic)
Spätestens an der Stelle dürfte es schwierig werden, wenn Du die Werte nur in einer Datenbank stehen hast.
Ich würde an Deiner Stelle die Skripte zu ändern, dass sie die Werte (auch?) direkt an FHEM übergeben. Also z.B. für jeden Sensor in FHEM ein Dummy anlegen und dann z.B. per so einer Konstruktion die Werte übergeben:
http://localhost:<fhem-port>/fhem?cmd=setreading%20dummy1%20reading1%20value1
Statt dummy1, reading1, value1 muss natürlich was sinnvolles hin.
Für den produktiven Betrieb sollte man noch eine spezielle FHEMWEB-Instanz ohne (oder mit festem) csrf-Token anlegen und gegen alles andere abschotten.
Das ganze ist meiner Meinung nach ziemlich einfach und gibt einem die volle Funktionalität eines richtigen FHEM-Geräts.
Du kannst Dir dann sogar das Schreiben in die Datenbank sparen, da FHEM das dann auch für Dich erledigen kann.
Gruß,
Thorsten
Danke für den Denkanstoß :)
Das wäre ein Ansatz, den ich zusätzlich einbauen würde, meine Daten werde ich im MySQL lassen,
aber die Aktualisierung per Script durchführen.
Wenn ich das geschafft habe, schreibe ich hier...
so einfach ist es leider doch nicht - auf dem fhem-Seite...
define AussenTemp dummy
danach einfach im Browser aufgerufen:
http://10.xxx.xxx.xxx:8083/fhem?cmd=setreading%20AussenTemp%20Temp01%2018.3
Kein Log, kein garnichts ...
Muss ich die Readings irgendwie noch definieren?
Mit httpmode auslesen denk ich mal, eifach mit der url wird das nicht gehen.
Hi,
ich habe das gerade genau so ausprobiert und es funktioniert wunderbar.
Ok, nicht ganz 100% genauso, da ich das auf derselben Maschine mache, wie auch mein FHEM läuft und ich es daher mit localhost statt IP-Adresse mache. Außerdem ist mein Spiel-FHEM nicht passwortgeschützt.
Also vielleicht auch mal auf der FHEM-Box selbst ausprobieren (mit wget oder so) und mal eine lokale FHEMWEB-Instanz ohne Passwortschutz anlegen.
Zitat von: franky08 am 29 April 2017, 23:57:55
Mit httpmode auslesen denk ich mal, eifach mit der url wird das nicht gehen.
Wahrscheinlich meinst Du HTTPMOD. ...und nein, das hat damit nichts zu tun. Wir wollen ja FHEM aufrufen und nicht umgekehrt.
Gruß,
Thorsten
Zitat von: germansleeper am 29 April 2017, 23:54:30Muss ich die Readings irgendwie noch definieren?
Jo, ein Dummy hat erst einmal nur das Reading state und ich denke nicht, dass setreading diese anlegt. Dazu gibt es das Attribut userreading. Aber erst einmal würde ich versuchen State zu setzen, dann kannst Du doch immer noch weiter schauen. Beim Dummy kann das Reading State weg gelassen werden, es reicht also http://localhost:<fhem-port>/fhem?cmd=set%20dummy1%20value1.
Trotzdem würde ich die Daten nicht 2x loggen, nur um die Temperaturkurve im FHEM darzustellen. Da bleibe ich bei meinem Vorschlag mit dem View und dem Zugriff auf Deine ursprüngliche DB. Für Aktionen ist das Event via HTTP an das Dummy besser. Aber warum sollte man 2x loggen?
Mein View funktioniert (fast) wunderbar, nur bin ich auf der Zielgeraden daran gescheitert, dass ich die Differenz zu dem jeweils vorherigen Wert bilden muss. Auch das funktioniert in einem View, doch leider geht der Rasperry da in die Knie, wenn es zu viele Zeilen werden. Aktuell denkt die DB schon fast eine Stunde über ein 'drop view history' nach. Aber ein reines 1:1 Abbild mit etwas angepassten Spaltennamen und evtl. noch manipulierten Werten innerhalb des Datensatzes ist kein Thema.
sparsame Grüße
Niels
Zitat von: Muschelpuster am 30 April 2017, 10:46:43
Jo, ein Dummy hat erst einmal nur das Reading state und ich denke nicht, dass setreading diese anlegt.
Dann hast Du das noch nie ausprobiert. Probier's aus, es funktioniert wunderbar.
Zitat
Dazu gibt es das Attribut userreading.
Das ist für etwas anderes gedacht.
Zitat
Aber erst einmal würde ich versuchen State zu setzen,
Nein, state macht immer Probleme. Keine gute Idee. Schau Dir mal die ganzen Threads nach dem Motte "dummy wird nicht in DBLog geschrieben" an.
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 30 April 2017, 10:59:25
Dann hast Du das noch nie ausprobiert. Probier's aus, es funktioniert wunderbar.
In der Tat. So lernt man hier permanent dazu. Klappt bei mir einwandfrei.
Zitat von: Thorsten Pferdekaemper am 30 April 2017, 10:59:25Nein, state macht immer Probleme. Keine gute Idee. Schau Dir mal die ganzen Threads nach dem Motte "dummy wird nicht in DBLog geschrieben" an.
Ich meinte nicht produktiv mit Logging (siehe meine Meinung dazu), sondern nur zum Testen, um sich langsam ran zu tasten.
lernfähige Grüße
Niels
Zitat von: germansleeper am 29 April 2017, 23:54:30
so einfach ist es leider doch nicht - auf dem fhem-Seite...
define AussenTemp dummy
danach einfach im Browser aufgerufen:
http://10.xxx.xxx.xxx:8083/fhem?cmd=setreading%20AussenTemp%20Temp01%2018.3
Kein Log, kein garnichts ...
Muss ich die Readings irgendwie noch definieren?
Fang' doch mal ganz klein an.
Fhem mit Browser aufmachen.
Oben in der FHEM-Komanndozeile "setreading AussenTemp Temp01 18.3" eingeben und Enter drücken.
Wenn das nicht funktioniert, läuft was ganz falsch.
Wenn es funktioniert, sehen wir weiter, was mit dem Webaufruf nicht stimmt.
Hi,
ich hatte vorhin noch was vergessen...
Zitat von: Muschelpuster am 30 April 2017, 10:46:43Trotzdem würde ich die Daten nicht 2x loggen, nur um die Temperaturkurve im FHEM darzustellen.
Deshalb würde ich es ja auch FHEM überlassen, den Kram in die DB zu schreiben.
Zitat
Mein View funktioniert (fast) wunderbar, nur bin ich auf der Zielgeraden daran gescheitert, dass ich die Differenz zu dem jeweils vorherigen Wert bilden muss.
Das ist bei "meinem" Ansatz ziemlich einfach, glaube ich. Man macht sich ein notify auf das Reading (geht auch mit userReading, aber für den Anfang würde ich das mit einem notify machen). Dieses notify liest ein anderes Reading "oldValue" oder so desselben Device und bildet die Differenz zum neuen Wert. Die Differenz wird dann in ein weiteres Reading "diffValue" geschrieben. Danach wird der neue Wert noch nach oldValue kopiert (mit setreading...). Ganz ohne Performance-Probleme...
Gruß,
Thorsten