Fröling: [ANNOUNCE] p4d - Visualisierung und Einstellung der S-3200 via COM1

update samples set value = '$value' where time = (select max(time) from samples) and address = '$id' and type = '$type';"

Beim Insert hab den aktuellen Zeitstempel genommen. sonst gibts ja Duplikate. Also 1 oder 2 sekunden später

Das geht nicht "time" ist ein Index und darf nicht doppelt vorkommen in der Tabelle. die anderen beiden Werte inssp und updsp könnten theoretisch mit dem gleichen Wert kommen, aber nicht time.

Bin mir jetzt nicht sicher was du mit eigenem Sensor meinst. Ich habe in der Tabelle valuefacts einen Parameter mit der Nummer 999 (0x3e7) angelegt. Der wird aber beim Abfragen der Heizung schon automatisch in die Tabelle samples geschrieben mit Wert Null, weils den in der heizung ja nicht gibt. Somit gibt es dort die Adresse 999, Type 'VA' und time schon. deshalb bin ich ja auch die idee gekommen, dass ich nur ein update mache.

genau das ist das Problem.... cool vielen Dank für deine Mühen.

@horchi,

und falls du irgendwann mal Zeit und Lust hast neben dem Pool buddeln, vielleicht bringen wir die Fehlermeldungen noch mit rein.

Deinen Vorschlag war:

{
"messages" : [
{
"state" : "gegangen",
"message" : "Aschebox voll, bitte entleeren",
"time" : "2019-08-29T21:38:39"
},
{
"state" : "gekommen",
"time" : "2019-08-29T21:38:39",
"message" : "Raumaustragung kontrollieren"
},
{
"state" : "quittiert"
"message" : "Steuerung neu gestartet",
"time" : "2019-08-29T21:38:39",
}
]
}

Das einfach Array an die anderen Baugruppen/Werte hinten dran hängen.

Vorschlag fürs Setup:
Aktiv-Flag: on/off
Anzahl Tage (0.. alle, 1 - xxxx ... xxxx Tage) --> wieviele Meldungen überschickt werden in Tagen

Ob noch eine aktuelle Störung vorliegt müsste ja über Stoermeldung_0x14
ersichtlich sein. Wäre für mich ein pragmatischer Ansatz um die
Meldungen zu sehen und ob eine Störung vorliegt.

hoppel,

auch in Ordnung für FHEM? Ist ja im Endeffekt eine ähnliche Struktur wie du das für die Messdaten brauchst für FHEM.

VG

Reachy

Zitat von horchi

hier erst mal die Version 0.3.29:

Code

2020-05-05:  version 0.3.29   
     - added: Syslog to WEBIF

klasse. Das macht das Analysieren komfortabler! läuft.

@Reachy Habe das gerade im FHEM Forum hinterfragt. Ich melde mich wieder.

Gruß Hoppel

Zitat von Reachy

@horchi,

und falls du irgendwann mal Zeit und Lust hast neben dem Pool buddeln, vielleicht bringen wir die Fehlermeldungen noch mit rein.

Deinen Vorschlag war:

{
"messages" : [
{
"state" : "gegangen",
"message" : "Aschebox voll, bitte entleeren",
"time" : "2019-08-29T21:38:39"
},
{
"state" : "gekommen",
"time" : "2019-08-29T21:38:39",
"message" : "Raumaustragung kontrollieren"
},
{
"state" : "quittiert"
"message" : "Steuerung neu gestartet",
"time" : "2019-08-29T21:38:39",
}
]
}

Das einfach Array an die anderen Baugruppen/Werte hinten dran hängen.

Vorschlag fürs Setup:
Aktiv-Flag: on/off
Anzahl Tage (0.. alle, 1 - xxxx ... xxxx Tage) --> wieviele Meldungen überschickt werden in Tagen

Ob noch eine aktuelle Störung vorliegt müsste ja über Stoermeldung_0x14
ersichtlich sein. Wäre für mich ein pragmatischer Ansatz um die
Meldungen zu sehen und ob eine Störung vorliegt.

hoppel,

auch in Ordnung für FHEM? Ist ja im Endeffekt eine ähnliche Struktur wie du das für die Messdaten brauchst für FHEM.

VG

Reachy

Alles anzeigen

Beta-User schreibt dazu folgendes:

Zitat von Beta-User

Deinen Beitrag davor hatte ich jetzt so verstanden, dass es ein "Feld" (einen konkreten Topic) gibt, in dem steht, ob aktuell ein Problem besteht. Damit wäre für mich "der Fisch geputzt", denn auf Events auf einen konkreten Datenpunkt kann man (einfach) automatisiert reagieren, was in irgendeiner history steht, ist mir (@MQTT) egal...

Zusätzlich habe ich meinen Thread im FHEM Forum auch nochmal zu älteren Diskussionen zu dieser Thematik durchsucht. Grundsätzlich ist die Aussage, dass FHEM damit klar kommt.

@Reachy Ein Frage noch: Was bedeutet "Das einfach Array an die anderen Baugruppen/Werte hinten dran hängen."? Kannst du mir das näher erläutern? Ein Topic für die Fehlermeldungen? Oder sollen die Fehlermeldungen zu den entsprechenden Baugruppen-Topics verteilt werden?

Ich glaub letzteres wäre sinnvoll, um die Fehlermeldungen da zu haben, wo sie hingehören. Das schrieb auch Beta-User neulich schonmal. Aber das ist wohl kaum umsetzbar, oder? Also wir es wohl auf alle Fehlermeldungen in einem eigenen Topic hinauslaufen.

Beta-User schrieb noch folgendes:

Zitat von Beta-User

Hmm, dann denke ich, dass es Sinn macht, nur bei _Hinzukommen_ einer Meldung _einen Wert_ zu senden, nämlich die neue Meldung. Darauf kann man dann reagieren, alles andere ist mMn. "kalter Kaffee von vorgestern"... (und informationstechnisch gut auf dem Web-Interface aufgehoben, wenn man es braucht/wissen will).

Rudi schrieb folgendes:

Zitat von rudolfkoenig

Es geht darum, dass ein Fehler nicht immer wieder gemeldet wird, sondern nur, wenn es auftaucht, einmal.
Sonst ist es aufwendiger etwas zu basteln, um darauf zu reagieren.

Aus Komplettsicht ist es sinnvoller sowas in FHEM zu filtern, wenn ich mich nicht irre, sollte das mit event-on-change-reading moeglich sein.

Passt das alles zusammen bzw. sind unsere gemeinsamen/unterschiedlichen Bedarfe umsetzbar?

Schön wäre, wenn wir dafür eine Option bekämen das de-/aktivierbar zu machen.

Viele Grüße Hoppel

Hallo Hoppel,

ich wiederhole jetzt nur was ich oben geschrieben habe, weil das die meisten Fragen aus meienr Sicht beantwortet.

Deine Frage zu was ist mit Array gemeint:

{

"messages" : [

{

"state" : "gegangen",

"message" : "Aschebox voll, bitte entleeren",

"time" : "2019-08-29T21:38:39"

},

{

"state" : "gekommen",

"time" : "2019-08-29T21:38:39",

"message" : "Raumaustragung kontrollieren"

},

{

"state" : "quittiert"

"message" : "Steuerung neu gestartet",

"time" : "2019-08-29T21:38:39",

}

]

}

hinter den aktuell gesendeten Parametern und Messwerten werden die oben aufgeführten Meldungen unter einem Topic "messages" übermittel. Alle Meldungen die ich heute in der Heizung ansehen kann, kann man dann auch in der Hausautomatisierung anzeigen.
Wie soll das Einsortieren denn passieren? Da müsste man ja alle bekannten Fehler den Baugruppe zu ordnen? Könnte meiner Ansicht nach nur über die Baugruppenkonfig manuelle erfolgen. Sehe ich ehrlich gesagt keinen Mehrwert und macht die Heizung heute ja auch nicht.

Mit den folgenden Optionen kann man das aktivieren oder nicht bzw. einschränken wieviele Meldungen gesendet werden:

Vorschlag fürs Setup:

Aktiv-Flag: on/off

Anzahl Tage (0.. alle, 1 - xxxx ... xxxx Tage) --> wieviele Meldungen überschickt werden in Tagen

Eine Reaktion der Hausautomation kann nur auf den Störmelder-Parameter (Störmeldung_0x14) erfolgen, der ja unabhängig davon schon mit gesendet wird.

Eine Logik, dass nur neue Meldung gesendet werden macht für meinen Zweck keinen Sinn, weil wenn ich die Hausautomation mal neustarten muss, sehe ich ich die Meldungshistorie nicht mehr, die mich schon interessiert.

Also wenn ich deinen Post richtig gelesen habe, ist der einze Unterschied, das für FHEM nur neue Meldungen gesendet werden soll. Reicht es dann nicht den Meldungszeitraum auf 1 Tag zu setzen? Oder man könnte Tag oder einen anderen Zeitraum auswäheln. Dann kommt halt nur für den Zeitraum lang die entsprechende Meldung mit? Wenn nicht würde das Setup so aussehen und ist deutlich aufwendiger zu programmieren:

Vorschlag fürs Setup:

Aktiv-Flag: on/off

Anzahl Tage (0.. alle, 1 - xxxx ... xxxx Tage) --> für wieviele Tage werden Meldungen übermittelt

nur neue Meldungen senden: on/off



optional: Baugruppentabelle erweitern für Zuordnung-Fehler --> Fehlermeldungen in die entsprechende Baugruppe einsortieren


Das sollte dann jetzt zumindest unseren Vorstellungen genügen, richtig?

@horchi,

wie siehst du das? Was davon wäre mit annehmbarem Aufwand machbar und würdest du überhaupt machen wollen?

VG

Reachy

@horchi Seit dem letzten Update funktioniert mein Autodiscovery im Home-Assistant nicht mehr von den Sensoren wird auf einmal nichts mehr geupdatet. Bin von Version 0.3.x irgendwas, auf 0.3.29 per deb Packet gegangen.
Was hat sich da jetzt geändert für mich?

Mfg
Johann

OK habs geschafft musste den Topic so einstellen: p4d2mqtt/sensor/<NAME>/state und das häckchen setzen bei Config Topic:

Zitat von Reachy

Eine Logik, dass nur neue Meldung gesendet werden macht für meinen Zweck keinen Sinn, weil wenn ich die Hausautomation mal neustarten muss, sehe ich ich die Meldungshistorie nicht mehr, die mich schon interessiert.

Ok, dann haben wir das gleiche Verständnis. Ich bin wie gesagt kein Entwickler. Ich habe es so hinterfragt, um zu vermeiden, dass wir aneinander vorbeireden. Die Situation hatten wir neulich bei „ein Topic pro Baugruppe“. Du hattest dann plötzlich, was du für Openhab brauchtest und ich nicht das, was ich für FHEM brauchte. Glücklicherweise hat horchi es dann nochmal erweitert und nun ist alles gut...

Zitat von Reachy

Also wenn ich deinen Post richtig gelesen habe, ist der einze Unterschied, das für FHEM nur neue Meldungen gesendet werden soll. Reicht es dann nicht den Meldungszeitraum auf 1 Tag zu setzen? Oder man könnte Tag oder einen anderen Zeitraum auswäheln. Dann kommt halt nur für den Zeitraum lang die entsprechende Meldung mit? Wenn nicht würde das Setup so aussehen und ist deutlich aufwendiger zu programmieren:

Vorschlag fürs Setup:

Aktiv-Flag: on/off

Anzahl Tage (0.. alle, 1 - xxxx ... xxxx Tage) --> für wieviele Tage werden Meldungen übermittelt

nur neue Meldungen senden: on/off



optional: Baugruppentabelle erweitern für Zuordnung-Fehler --> Fehlermeldungen in die entsprechende Baugruppe einsortieren


Das sollte dann jetzt zumindest unseren Vorstellungen genügen, richtig?

Alles anzeigen

Hört sich nach einer guten Lösung an. So könnte sich das jeder an die eigenen Bedürfnisse oder die der Hausautomatisierungssoftware anpassen.

Mal sehen, was horchi dazu sagt.

Viele Grüße Hoppel

EDIT:

@Reachy Wir sind beide noch nicht mal einen Monat hier angemeldet und haben jeweils schon über 50 Beiträge. Wahnsinn...

@horchi Danke dir, dass du das mit uns Neulingen so mitgemacht hast.

Hallo

eine Frage zwischendurch.

Wie kann man sich denn im WebIF anmelden?
Irgendwo muss man ja erst mal einen User anlegen.

Gruß
meute

Benutzer: p4
Standard-Passwort: p4-3200

Zitat von horchi

hier erst mal die Version 0.3.29:

Code

2020-05-05:  version 0.3.29   
     - added: Syslog to WEBIF

Hallo Horchi,
ich finds ja weiterhin interessant, die MQTT Integration zu beobachten. Allerdings bekomme ich die neueren Versionen bei mir nicht mehr zum Laufen, die alten vor einigen Wochen liessen sich problemlos übernehmen,
aktuelle paho-library läuft auch noch durch, aber dann kommt immer die gleiche Fehlermeldung bei make des p4d.
_________________________________
[14:42:23] openhabian@openHABianPi:/usr/src/linux-p4d$ sudo make clean all HASSMQTT=yes
rm -f */*.o *.o core* *~ */*~ lib/t *.jpg
rm -f p4d dbchart p4 p4d-0.3.30.tgz
rm -f com2
if [ ! -d ~/build/paho.mqtt.c ]; then \
mkdir -p ~/build; \
cd ~/build; \
git clone https://github.com/eclipse/paho.mqtt.c.git; \
sed -i '/if test ! -f ..DESTDIR..{libdir}.lib..MQTTLIB_C..so..{MAJOR_VERSION.; then ln -s/d' ~/build/paho.mqtt.c/Makefile; \
sed -i '/\- ..INSTALL_DATA. .{blddir}.doc.MQTTClient.man.man3.MQTTClient.h.3 ..DESTDIR..{man3dir}/d' ~/build/paho.mqtt.c/Makefile; \
sed -i '/\- ..INSTALL_DATA. .{blddir}.doc.MQTTAsync.man.man3.MQTTAsync.h.3 ..DESTDIR..{man3dir}/d' ~/build/paho.mqtt.c/Makefile; \
sed -i s/'int rc1 = sem_getvalue.sem, .val.;.*'/'sem_getvalue(sem, \&val);'/ ~/build/paho.mqtt.c/src/Thread.c; \
sed -i s/'rm [$]'/'rm -f $'/g ~/build/paho.mqtt.c/Makefile; \
fi
Klone nach 'paho.mqtt.c' ...
remote: Enumerating objects: 68, done.
remote: Counting objects: 100% (68/68), done.
remote: Compressing objects: 100% (53/53), done.
remote: Total 7125 (delta 38), reused 36 (delta 15), pack-reused 7057
Empfange Objekte: 100% (7125/7125), 2.80 MiB | 1.93 MiB/s, Fertig.
Löse Unterschiede auf: 100% (5290/5290), Fertig.
cd ~/build/paho.mqtt.c; \
make -s; \
sudo rm -f /usr/local/lib/libpaho*; \
sudo make -s uninstall prefix=/usr; \
sudo make -s install prefix=/usr
OSTYPE is Linux
src/Thread.c: In function ‘Thread_post_sem’:
src/Thread.c:326:7: error: ‘rc1’ undeclared (first use in this function)
if (rc1 != 0)
^~~
src/Thread.c:326:7: note: each undeclared identifier is reported only once for each function it appears in
Makefile:254: die Regel für Ziel „build/output/libpaho-mqtt3c.so.1.3“ scheiterte
make[1]: *** [build/output/libpaho-mqtt3c.so.1.3] Fehler 1
OSTYPE is Linux
src/Thread.c: In function ‘Thread_post_sem’:
src/Thread.c:326:7: error: ‘rc1’ undeclared (first use in this function)
if (rc1 != 0)
^~~
src/Thread.c:326:7: note: each undeclared identifier is reported only once for each function it appears in
Makefile:254: die Regel für Ziel „build/output/libpaho-mqtt3c.so.1.3“ scheiterte
make: *** [build/output/libpaho-mqtt3c.so.1.3] Fehler 1
Makefile:183: die Regel für Ziel „paho-mqtt“ scheiterte
make: *** [paho-mqtt] Fehler 2
_____________________________________________

Hab leider keine Idee mehr, an was das liegen könnte, vielleicht hast Du einen Tip?