Beiträge von Reachy

Wie starte ich das? gdb...... ?? Mehr weiß ich dazu leider (noch) nicht

Zitat von horchi

Code

2020-05-01:  version 0.3.26
   - change: Moved many config options fron p4d.conf to WEBIF
   - change: Minor rework of config page
   - added:  optional user/password for MQTT

nach den Update konnte ich starten. Dann hab User und Passwort für MQTT eingetragen und die Konfig gespeichert. Jetzt startet der Dämon aber nicht mehr. Kann es sein, dass beim Speichern der neuen Paramter noch was nicht passt und die Konfig jetzt kaputt.

pi@raspberrypi:~ $ sudo systemctl status p4d
● p4d.service - Deamon to capture data of the P4 pellet heating
Loaded: loaded (/etc/systemd/system/p4d.service; enabled; vendor preset: enabled)
Active: failed (Result: signal) since Fri 2020-05-01 16:26:34 CEST; 18s ago
Process: 1047 ExecStart=/usr/bin/p4d (code=killed, signal=SEGV)

Mai 01 16:26:34 raspberrypi systemd[1]: p4d.service: Service RestartSec=100ms expired, scheduling restart.
Mai 01 16:26:34 raspberrypi systemd[1]: p4d.service: Scheduled restart job, restart counter is at 5.
Mai 01 16:26:34 raspberrypi systemd[1]: Stopped Deamon to capture data of the P4 pellet heating.
Mai 01 16:26:34 raspberrypi systemd[1]: p4d.service: Start request repeated too quickly.
Mai 01 16:26:34 raspberrypi systemd[1]: p4d.service: Failed with result 'signal'.
Mai 01 16:26:34 raspberrypi systemd[1]: Failed to start Deamon to capture data of the P4 pellet heating.

Läuft der Dämon bei dir ohne Probleme?

VG

Reachy

@horchi,

• Was ich wirklich wichtig fände ist, dass die Verbindung zum MQTTServer mittels User und Passwort gesichert ist. Aktuell hab ich das abgeschalten, weil ja der p4d sich sonst nicht verbinden kann. Da es für diejenigen, die keine User-Passwort-Anmeldung eingestellt haben auf dem MQTT-Server, keine Auswirkung hätte, ob dieses Info mit kommt beim connect oder nicht, könnte man das unproblematisch einbauen. Vielleicht hast mal Zeit und Lust. Sind ja nur die 2 zusätzlichen Parameter im Setup und beim Connect-Aufruf.

Viele Grüße

Reachy

@horchi,
Ja, da hast du vollkommen recht. Ich hatte gestern Abend noch mal Version 0.3.23 drüber installier. Ich hatte vermutet, dass vielleicht während der Installation irgend ein File nicht upgedatet werden konnte. War aber nicht so. Egal. Jetzt gehts.

hoppel,

könnten wir uns dann auf die Fehlermeldungen konzentrieren, sofern keine Fehler mehr da sind.. Ich denke aktuell bekommt ihr die Daten wie FHEM sie benötigt. Die anderen noch angemerkten Punkte sind meines Erachtens sinnvolle Optimierung, aber haben keinen funktionellen Mehrwert, und haben für mich auch keine Prio. Mir wäre geholfen, wenn wir den letzten Vorschlag für die Fehlermeldungen aufgreifen und mal eine Vorgabe für Horchi festlegen. Dann kann er das machen, wenn er mag und es bei ihm rein passt.

VG

Reachy

Zitat von horchi

auf den ersten Blick würde ich sagen das sollte passen

Mit Version 0.3.25 kommen jetzt auch die einzelnen Topics mit <GROUP>

jep, so hab ich das verstanden.

Gruß
Reachy

Ich hatt <GROUP> im Topic Namen: p4d2mqtt/sensor/<GROUP>/state

wie prüfe ich ob das in der config-Tabelle angekommen ist?

Ergebnis im MQTT-Explorer:

Ich brauchs ja nicht, wollts nur testen. Weiss grad nicht, was ich falsch mache.... Vielleicht gehts ja bei Hoppel.. Dann liegts irgendwo bei mir..

VG

Reachy

Zitat von horchi

Ahhh ich weiß woran das liegt, ich nehme an du verwendest nicht das Paket sondern baust selbst!? Dann hast du sicher noch die Version 0.3.22, richtig?
Ich hatte nur das Paket aktualisiert und noch nicht ins git gepushed, das habe ich jetzt nachgeholt

Nein ich lade das Paket, weil der einfach update nicht funktioniert bei mir. bekomme da Fehlermeldungen... Hab die Version 0.3.23-GIT93ae62c / 0.3.23 drauf

VG

Reachy

Danke. extrem flott bist du... Hab mal upgedatet. und folgendes im Setup eingestellt:

• p4d2mqtt/sensor/<NAME>/state
  --> wie erwartet. lauter Einzelwerte unter einem Topic
• p4d2mqtt/sensor/state
  --> wie erwartet: vernünftiger JSON
• p4d2mqtt/sensor/<GROUP>/state
  --> Ergebnis unerwartet:

MQTT-Explorer zeigt:
p4d2mqtt
-->sensor
--><GROUP>
-->state={"Heizung": {"Tuerkontaktschalter_0x0": {"value": "0.00"},"Status": {"value": "Fe.......}

Es wird kein separates Topic erstellt sondern der Templatename <GROUP> einfach verwendet. Ist an dem Setup was falsch?

Denke mal mein Problem sitzt wieder vor dem Bildschirm. Was mach ich falsch?

Gruß

Reachy

also in Openhab is grundsätzlich egal wie die Daten kommen. So wie jetzt der JSON kommt, scicken vielen MQTT-Geräte ihre Daten. Die bei mir eigentlich überwiegen.. ich flashe alles was geht mit Tasmota. Das zusammenfassen in Gruppen machts vielleicht schöner lesbar für den Menschen. Mir reicht im Prinzip die Gruppe Heizung. Mit JSONPATH$ wird der JSON geparst.. wenn mehrere Gruppen da sind, ist die Konfiguration dann deutlich aufwendiger. Ist aber nur meine persönliche Meinung.
so wie es jetzt is, hab ich es eigentlich erwartet.
Also für Openhab gehts so oder so. Aber 2 Wege sollten wir nicht machen.
Wenn pro Baugruppe ein Topic gemacht wird sind wir doch fast beim Ausgangsformat, oder seh ich das falsch?

Viele Grüße

Reachy.

Zitat von horchi

Ganz anderes Thema ....

hat hier jemand das Fröling Windows Programm welches auch an COM1 hängt? Wenn ja, kann man über dieses die Funktionen der Taster an der Heizung (Kessel an/aus, Party, Schornsteinfeger, ...) auch auslösen?

Leider nein.

Zitat von hoppel118

Da ich mir gerade nicht sicher bin, ob wir bezüglich „ein Topic pro Baugruppe“ evtl. aneinander vorbeigeredet haben...

@Reachy Passt das in Openhub auch, wenn pro Baugruppe ein Topic existiert? Kann ja aber eigentlich nicht schaden, da man die Baugruppen ja nicht zwingend konfigurieren muss. Wenn man es nicht macht landet alles in der einen Baugruppe „Heizung“.

Gruß Hoppel

klar geht auch in Openhab. JSON kann man immer auslesen, egal wie verschachtelt das ist. Wobei für mich das so wie es jetzt ist, passen würde und ich auch so verstanden hatte. Die anderen MQTT-Geräte die ich am Laufen haben, schicken das auch so . Funktioniert aber auch mit einzelnen Topics.

Zitat von horchi

----
Viele Grüße Jörg

Wegen der Fehler-Messages, schreibt wie ihr es haben möchtet - wenn es ins Design passt setzte ich es um.

@horchi,

... hatte überlesen, dass ich <Name> aus dem Topic nehmen muss. Json kommt jetzt mit den Gruppen und Units natürlich auch beim ersten Mal! Perfekt.

Danke für die schnelle Umsetzung

Wegen der Fehler-Meldung würde ich auf deinen Vorschlag zurück kommen. Bin mir nicht merh sicher was wir als letztes tatsächlichgesgat haben. drum fasse ich nochmal zusammen, was mir noch einfällt.

{
"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",
}
]
}

Array an die anderen Werte hinten dran hängen.

Vorschlag fürs Setup:
Aktiv-Flag: on/off
Anzahl Tage (0.. alle, 1 - xxxx ... xxxx Tage)

Ob noch eine 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,

letzte Diskussion darüber Sollen wir so das mal machen?

VG

Reachy

@horchi,

Update ist drauf. Baugruppen kann ich anlegen und zuordnen. MQTT-Nachrichten sehen nach wie vor aus wie vorher..? Mehr Details sehe ich nicht. Muss ich da noch was im Setup zusätzlich machen? Hab ich was übersehen?

hoppel,

wie siehts bei dir aus? gehts da?

Viele Grüße

Reachy

Zitat von horchi

genau jetzt habe ich die 0.3.23 hochgeladen.

Diese unterstützt nun auch die Baugruppen. Die Baugruppen müsst ihr euch im WEBIF anlegen und zuordnen - per default ist erst mal alles in der Gruppe 'Heizung'

Muss ich ja auch dann gleich mal ein Update machen...Merci!

@horchi,
Perfekt. Pizza is schon mal unterwegs

hoppel,
Danke für die Koordination

Hi Hoppel,

Bitte nicht falsch verstehen. War lediglich meine Meinung dazu ohne jemand zu nahe treten zu wollen. Ich bin ja froh dass das Thema überhaupt verfolgt wird. Ich wollte eigentlich damit sage, das ich keine Lösung für mich alleine möchte, sondern das für "alle" passen sollte. Und eine Umsetzung von Anforderungen in Software ist immer auf eine klare Darlegung der Fakten angewiesen. Wobei die Umsetzung oft unterschiedlich angegangen wird. Und würde ein Jörg zum Schluss kommen, er möchte das so nicht umsetzen, wärs schade aber ok. Ist sein Baby.

zu deiner Frage. Für mich würds passen, wie Jörg es beschrieben hat. Die Array-Variante sehe ich als die bessere Variante.

Viele Grüsse

Reachy

Hallo Zusammen,

also ich finde die Darstellung Von Beta-User aus technischer Sicht durch aus richtig, aber nur einseitig betrachtet.
Würde bedeuten man soll entweder

• in ein anderes System schaun um die Fehler zu sehen
• oder eine andere Technik verwenden.

Punkt 2 finde ich zu aufwendig eine 2. Übertragungstechnik auf zu setzen, nur weil es keine direkten Datenpunkte gibt. Wobei für mich Fehlermeldungen 1 - n auch Datenpunkte darstellen, allerdings nicht zu einer Hardware. Ist aber bei "Uhrzeit" aus meiner Sicht auch so. Aber da kann man ewig hin und her diskutieren, wenn die Meinungen so unterschiedlich sind.

Ich will das Thema nicht überstrapazieren. Wenns nicht sein soll dann ist es so. Ich fände es aber schade, weil die Umsetzung technisch gesehen einfach wäre.

Viele Grüße

Reachy

Zitat von horchi

verstehe ich das richtig, ihr möchtet die Fehlermeldungen auf einem separaten Topic und nicht auf dem selben wie die Daten/Temperaturen/etc. ?
und dann so:

Code

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

Alles anzeigen

oder als Array:

Code

{
   "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",
      }
   ]
}

Alles anzeigen

/Edit

jeweils mit Key zum zuordnen, in Variante 1 wäre der Bezeichner (message1) der Key in Variante zwei würde ich "key":"0123" mitgeben

Muss nicht unbedingt ein separates Topic sein. War nur ein erster Vorschlag. Kann genauso mit den Messwerten zusammen gesendet werden, aber ich denke das Array wäre aus meiner Sicht i.O.!

Zitat von horchi

euren Posts nach passt das vorgeschlagene JSON Format so, dann würde ich das so umsetzen.
Noch eine Frage dazu, der FHEM Vorschlag das Einheiten und Beschreibung nur initial gesendet werden passt auch für Openhab?

Die Baugruppen und Fehlermeldungen kommen dann im nächsten Schritt.

Ja, JSON passt
Und Einheiten und Beschreibungen nur initial, würde auch passen.

Viele Grüsse

Reachy