Hier hier geschrieben werde ich das zum Download angebotene fertige Debian Paket auf bookworm 64 bit umstellen.
Passiert vermutlich diesem Wochenende. Wenn danach den p4d aktualisieren möchtet heißt es entweder auf bookwom updaten oder aus den Quellen bauen.
Cool, habe mich schon gefragt, wann das endlich passiert. Ich freue mich, danke dir! 😃
Mal sehen, wann ich die Zeit finde, mich damit auseinanderzusetzen.
Danke dir und alle die an den Home Assistant Optimierungen mitgearbeitet haben.
Guten Rutsch ins neue Jahr!
Gruß Hoppel
Moin Leute,
hatte jetzt schon länger den folgenden Fehler im Log und p4d ist einfach gar nicht mehr gestartet:
Oct 7 16:11:21 rpi4 p4d[848]: /usr/bin/p4d: error while loading shared libraries: libwiringPi.so: cannot open shared object file: No such file or directory
Oct 19 10:08:24 rpi4 p4d[616]: /usr/bin/p4d: error while loading shared libraries: libwiringPi.so: cannot open shared object file: No such file or directory
Oct 19 10:09:31 rpi4 p4d[795]: /usr/bin/p4d: error while loading shared libraries: libwiringPi.so: cannot open shared object file: No such file or directory
Oct 19 10:10:01 rpi4 p4d[801]: /usr/bin/p4d: error while loading shared libraries: libwiringPi.so: cannot open shared object file: No such file or directory
Oct 19 10:10:32 rpi4 p4d[803]: /usr/bin/p4d: error while loading shared libraries: libwiringPi.so: cannot open shared object file: No such file or directory
Oct 19 10:11:02 rpi4 p4d[805]: /usr/bin/p4d: error while loading shared libraries: libwiringPi.so: cannot open shared object file: No such file or directory
Oct 20 10:19:52 rpi4 p4d[640]: /usr/bin/p4d: error while loading shared libraries: libwiringPi.so: cannot open shared object file: No such file or directory
Oct 20 10:32:20 rpi4 p4d[843]: /usr/bin/p4d: error while loading shared libraries: libwiringPi.so: cannot open shared object file: No such file or directory
Oct 20 10:32:51 rpi4 p4d[847]: /usr/bin/p4d: error while loading shared libraries: libwiringPi.so: cannot open shared object file: No such file or directory
Oct 20 10:33:21 rpi4 p4d[849]: /usr/bin/p4d: error while loading shared libraries: libwiringPi.so: cannot open shared object file: No such file or directory
Oct 20 10:33:51 rpi4 p4d[851]: /usr/bin/p4d: error while loading shared libraries: libwiringPi.so: cannot open shared object file: No such file or directory
Nov 3 17:04:39 rpi4 p4d[613]: /usr/bin/p4d: error while loading shared libraries: libwiringPi.so: cannot open shared object file: No such file or directory
Nov 3 17:05:23 rpi4 p4d[822]: /usr/bin/p4d: error while loading shared libraries: libwiringPi.so: cannot open shared object file: No such file or directory
Nov 3 17:05:53 rpi4 p4d[829]: /usr/bin/p4d: error while loading shared libraries: libwiringPi.so: cannot open shared object file: No such file or directory
Nov 3 17:06:23 rpi4 p4d[831]: /usr/bin/p4d: error while loading shared libraries: libwiringPi.so: cannot open shared object file: No such file or directory
Nov 3 17:06:53 rpi4 p4d[833]: /usr/bin/p4d: error while loading shared libraries: libwiringPi.so: cannot open shared object file: No such file or directoryNun habe ich endlich mal die Zeit gefunden, mich damit auseinander zu setzen. Die Lösung ist:
sudo apt-get install wiringpiSource: https://github.com/unosquare/r…62#issuecomment-525948886
Gruß Hoppel
Mein Data Topic Name sieht wie folgt aus:
p4d2mqtt/<GROUP>/stateHattest du <GROUP> probiert?
Außerdem gibt es noch die Möglichkeit Baugruppen zu definieren. Diese müssen dann im IO Setup zugeordnet werden. Ist das evtl. das was du suchst?
Ich verwende FHEM, also keine Ahnung von iobroker. 
Gruß Hoppel
Ok, alles klar, dann machen wir das so. Danke erstmal
Ja klar. Ich werde es sowieso ausprobieren. Die SD-Karte neu aufzusetzen dauert ja nur 10 Minuten. Ich wollte jedoch verstehen, was eigentlich die Anforderung ist, damit das Script funktioniert. Muss es Raspberry Pi OS (Raspbian) sein? Oder geht es grundsätzlich auch mit einem Standard Debian? Mit Ubuntu funktioniert es evtl. eher nicht?
Das ist schonmal gut! 
Danke dir für die zügige Rückmeldung.
Wie schätzt du meine Chancen mit dem p4d Script ein? Hast du das Script verwendet oder selbst gebaut?
Hallo in die Runde,
bevor ich mit einem kleinen Bastelprojekt loslege, habe ich mal eine Frage. Ich habe mir "versehentlich" einen NanoPi Neo gekauft. Das gute stück hat ein kleines OLED Display und 3 Buttons, über die man sich ein paar Systeminformationen anzeigen lassen und das System ausschalten kann. Der Formfaktor ist wirklich genial klein. Ich spiele nun mit dem Gedanken meinen p4d Raspberry 4 durch dieses Gerät zu ersetzen. Der rPi 4 erscheint mir für dieses Projekt sowieso ziemlich überdimensioniert.
Das Gerät ist mit Armbian und mit UbuntuCore kompatibel. Ich habe die Hoffnung, dass ich mit Armbian einfach horchi's raspberry script ausführen kann und so p4d ohne großen Aufwand zum Laufen bekomme.
uname -a
Linux nanopineo 5.15.48-sunxi #22.05.3 SMP Wed Jun 22 07:35:10 UTC 2022 armv7l GNU/Linuxcat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 38.85
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5
processor : 1
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 38.85
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5
processor : 2
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 38.85
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5
processor : 3
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 38.85
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5
Hardware : sun8i
Revision : 0000
Serial : 02c000816978def6Wie seht ihr das? Wie stehen meine Chancen. Armbian ist als Stretch, Buster und Bullseye verfügbar. Verwendet hier schon jemand Bullseye? Läuft das? Oder soll ich doch lieber auf Buster gehen?
Danke und viele Grüße Hoppel
das autocreate ist auch prima! Schön wäre wenn man konfigurieren kann für welche Topics (Basis) das passiert, am besten mit Wildcard ab eine bestimmten Basis dann wäre das Problem m.E. gelöst.
Wie gesagt m.E. ist ein MQTT Service ein zentraler Dienst, wenn ein Programm da auf alles reagiert finde ich schräg. Bei den Topics arbeitet man deswegen mit Namens-Konventionen und legt nicht alles auf oberster Ebene an, der p4d zum Beispiel legt alle Topics die er erzeugt unterhalb von p4d2mqtt an.
Die Topics welche für die Hausautomatisierung geschrieben werden kannst du konfigurieren, wenn du dort z.B. p4d2mqtt/fhem/ als Basis verwendest und dann FHEM sagst das es nur auf alles unterhalb lauschen soll, also auf p4d2mqtt/fhem/# (was m.E. gehen sollte) ist das Problem aus meiner Sicht gelöst.
Der p4d lauscht auch nicht auf allem was es gibt, er lauscht auf wenige fest verdrahtete Topics unterhalb p42mqtt plus auf die welche man explizit konfiguriert.
Soweit zu den Topics, zum Payload schreibe ich noch separat etwas.
OK, danke für die Erläuterung. Mit "p4d2mqtt/fhem/" sollte es klappen, da bin ich bei dir.
Das ist der Korrektur einer falschen Bezeichnung innerhalb des p4d geschuldet. Der Hinweis kam hier aus dem Forum und war berechtigt, ich hatte diesen Sensor falsch bezeichnet - nun ist es richtig.
OK, verstehe. Das werde ich bei mir dann auch mal korrigieren.
Der Payload im JSON Format wurde um die JSON Elemente "state" und "brightness" erweitert. Es gibt Sensoren/Aktoren (wenn auch 'brightness' nicht im Kontext der Heizung) für welche diese Werte benötigt werden. 'state' ist bei logischen Sensoren welche nur AN/AUS bzw. 1/0 kennen gefüllt (JSON Format boolean) und 'value' bei Werten (JSON Format real).
Wobei das mit dem Format boolean nicht immer zutrifft, je nach Konfiguration kann es auch sein das stattdessen der state noch im String Format mit "ON" / "OFF" übertragen wird - das ist ein (nich) Zugeständnis an diverse Haussteuerungen welche nicht mit logischen Werten umgehen können - z.B. der HomeAssitant erwartet das - so weit ich mich erinnern kann - so. Auch dasvon möchte ich in einer der nächsten Versionen weg, es ist bei json ja klar definiert wie logische Werte abzubilden sind.
brightness möchte ich noch je nach Typ des Sensors einschränken. Das ist noch etwas Arbeit und ich weiß noch nicht wann ich das angehe (hier fehlt mir noch ein weiterer Sensor Typ im Handling innerhalb des p4d).
Zu demMQTT Interface fehlt zugegeben im Wiki noch etwas Dokumentation.
Wenn das bei json klar definiert ist, wie mit logischen Werten umzugehen ist, wird auch FHEM das hinbekommen.
Ich werde die topics dann demnächst mal entsprechend umbauen und vrsl. das Device in FHEM ebenfalls neu anlegen. Aber das braucht Zeit.
Habe gerade mal deine letzte Version installiert.
Es läuft so weit erstmal alles wieder seit ca. 10Min. p4d.log und syslog sind absolut still. Die Time drifts sind nun auch nicht mehr sichtbar. Sehr schön!
Vielen Dank bis hierhin erstmal!
Schönen Abend noch, Gruß Hoppel
nein, es war auch mal so das man unterschiedliche Broker ansprechen konnte, das habe ich auf vielfachen Wunsch ausgebaut.
Und wenn dich eine Hausautomatisierung auf alle Topics eines Broker subscribed und auf alle reagiert ist das m.E. ein Bug, Ein MQTT Broker ist nach meinem Verständnis schon was zentrales was von vielen Programmen und Diensten gleichzeitig verwendet werden kann, wenn das einer Highlander (es kann nur einen geben) spielt - so wie FHEM das wie ich dich verstehe macht - ist das schon schräg.
Bei NodeRed und auch beim p4d stellt man ein welche Topics man lauschen möchte bzw. es ginb auch welche auf die per default gelauscht wird, eben aber nicht einfach pauschal auf alles.
Das macht meine Hausautomatisierung nicht per se. Natürlich kann ich autocreate (von FHEM Devices) auch deaktivieren. Das macht mir aber das Leben schwerer...
Schön wäre, wenn ich diese Topics entweder deaktivieren oder das was da übertragen wird meinen persönlichen Baugruppen zuordnen könnte. ICh weiß nicht, ob du das irgendwie unter "IO Setup" konfigurierbar machen könntest. Ich sehe es so, dass alles was ich nicht definiert habe und übertragen wird, erstmal so nicht ganz richtig sein kann. Vielleicht ist diese Ansicht falsch. Ganz ehrlich ich stecke in dem ganzen MQTT Zeug und in den absoluten Tiefen von FHEM auch nicht so tief drin. Mein Robomäher wird bspw. auch per MQTT an FHEM angebunden, allerdings läuft das zusätzlich noch über Amazon Web Services...
Da aber mittlerweile alles, was ich so an Technik besitze, in FHEM läuft, sehe ich kein Anlass zum Wechsel der Hausautomation. Dann sammle ich wahrscheinlich die Erfahrung, die du schon gesammelt hast, irgendwie funktioniert dies nicht und das nicht und manches funktioniert einfach anders. Bei FHEM habe ich nun zumindest den Überblick den ich brauche, um damit einigermaßen klarzukommen.
Wenn du das nicht anpassen willst, ist das auch kein Ding. Dann muss ich schauen, wie ich das in FHEM versteckt bekomme.
Wo siehst du p4d2mqtt//state ? in deinem Log Ausschnitt oben ist es nicht zu sehen.
Ich glaub ich habe gerade verstanden, wie man hier zitiert. Man markiert sich die Textstelle und sagt das im PopUp "Zitat einfügen".
Zurück zum Thema: Das sehe ich in dem Device, dass FHEM anlegt:
Evtl. ist da auch irgendwas mit meinem eigenen p4d2mqtt Device schief gegangen durch die ganze Updaterei. Das Device mit diesen 3 topics habe ich bis zum p4d Update so noch nicht gesehen. Ich komme von v.0.7x. Evtl. muss ich in FHEM p4d2mqtt einmal komplett neubauen.
Mir ist außerdem an meinem p4d2mqtt Device in FHEM aufgefallen, wo ich diverse Status sammle, dass dort der Betriebsmodus seit dem Update nicht mehr aktualisiert wird und stattdessen nun "Betriebsart_Kessel_value" auftaucht. Das müsste ich jetzt noch über jsonMap in FHEM in Form bringen und das Reading "Betriebsmodus" löschen.
Wie kann das sein, dass durch das p4d Update aus "Betriebsmodus" das Reading "Betriebsart Kessel" wird? Die Steuerung des Holzscheitkessels hat kein Update erhalten.
Bei den SubDevices für die Heizkreise ist in FHEM auch einiges durcheinander geraten. Das sind anscheinend einfach Sachen dazu gekommen, bspw.:
HKMischerAUF_0x4_brightness
HKMischerAUF_0x4_state
Das gab es vor dem Update so nicht, wie an dem jsonMap zu erkennen ist. Vorher gab es nur:
HKMischerAUF_0x4_description:0
HKMischerAUF_0x4_unit:0
HKMischerAUF_0x4_value:HKMischerAUF
Wo kommt das denn auf einmal her?
Hast du dazu eine Erklärung?
Wenn nicht, richte ich demnächst mein ganzes p4d2mqtt Device inkl. der SubDevices einmal komplett neu in FHEM ein.
Wie dem auch sei. Ich bin immer noch sehr begeistert von dem was hier geschaffen hast.
Schönes Wochenende erstmal!
Gruß Hoppel
das ping topic dient einem keep alive check für mqtt, so kann man besser erkennen ob ein reconnect nötig ist.
Das changes topic bekommt in einer recht ausführlichen Form alle Änderungen von Werten und Status, unterscheidet sich vom Interface zu Haussteuerungen darin das es nur bei Änderungen informiert wird. Es soll dem anbinden von NodeRed dienen um dort auf Änderungen reagieren zu können. Ich verwende bspw. quasi den p4d (eine weitere Instanz ohne den Heizungscode) als Hausautomatisierung und dabei NodeRed für bestimme Trigger und Timing Aufgaben.
Wie es beim state Topic zu den zwei Slashes kommt muss ich mir mal anschauen
OK, verstehe. Nodered funktioniert also wieder anders. In FHEM wird halt ein device angelegt mit dem ich so erstmal nichts anfangen kann und da werden meiner Ansicht nach die ganze Zeit unnötiger Weise Daten an meine HAusautomatisierung übertragen, die ich bereits in einem eigenen topic habe.
Kann ich die Inhalte dieser 3 topics irgendwie meinen eigenen topics zuweisen?
Ich muss mich jetzt erstmal wieder um meinen Sohn kümmern. Ich melde mich später nochmal.
Wahnsinn, wie kompliziert ist das denn hier im Forum die Zitate auseinanderzunehmen...
CodeDiese Schaltfläche hat bei mir (macOS) sowohl in Chrome als auch in Safari keine Funktion.auch wenn du vorher etwas einträgst?
Jo, das war die entscheidende Info. Ich musste natürlich links daneben noch den Titel hinschreiben.
Danke
>Ich bin allerdings noch nicht dahinter gestiegen, wie ich mehrere Reiter/Seiten/Gruppen im Dashboard erstelle.
Setup Dashboard, dann ganz oben rechts, Blatt Papier mit +, Dashboard hinzufügen.
OK, da habe ich natürlich schon hingeklickt, wenn du folgendes meinst:
Diese Schaltfläche hat bei mir (macOS) sowohl in Chrome als auch in Safari keine Funktion.
Woran kann das nun wieder liegen?
die Timedrift zw. dem PI und der Heizung wird solange es eine gibt und sie konfiguriert ist alle ~2 Minuten gemeldet.
Nachts wird dann die Uhr der Heizung gestellt (wenn im Setup aktiviert), wenn das klappt sollte die Meldung morgen weg sein.
Perfekt! Verstanden! Das Stellen der Uhr Nachts ist bei mir aktiviert. Schaue ich mir dann morgen mit der nächsten Version auch gerne wieder an.
Schaut hier eigentlich sonst niemand in seine Logs?
ja das hast du richtig verstanden. Genauer, 'Aufzeichnen' bedeutet das die Werte des Sensors nicht nur für die Anzeige aktualisiert werden sondern auch Historisch in der Datenbank gespeichert werden, das ist u.a. für die Charts nötig.
OK, auch verstanden.
okay stimmt, habe leider eine Kleinigkeit übersehen, versuch mal mit der 0.9.32
Sehr cool, jetzt haben wir es! Die Reconnect Meldungen sind weg, syslog ist auch schick!.
Vielen, vielen Dank, dass du dich da so reingehängt hast. TOP!!!
Eine Kleinigkeit sehe ich jetzt noch im p4d.log:
Feb 18 13:28:01 rpi4 p4d: Time drift is -16 seconds
Feb 18 13:30:11 rpi4 p4d: Time drift is -16 seconds
Feb 18 13:32:21 rpi4 p4d: Time drift is -16 seconds
Feb 18 13:34:31 rpi4 p4d: Time drift is -16 seconds
Feb 18 13:36:41 rpi4 p4d: Time drift is -16 seconds
Feb 18 13:38:51 rpi4 p4d: Time drift is -16 seconds
Feb 18 13:41:01 rpi4 p4d: Time drift is -16 seconds
Feb 18 13:43:11 rpi4 p4d: Time drift is -16 seconds
Feb 18 13:45:21 rpi4 p4d: Time drift is -16 seconds
Feb 18 13:47:31 rpi4 p4d: Time drift is -16 seconds
Feb 18 13:49:41 rpi4 p4d: Time drift is -16 seconds
Feb 18 13:51:51 rpi4 p4d: Time drift is -16 seconds
Feb 18 13:54:01 rpi4 p4d: Time drift is -16 seconds
Feb 18 13:56:11 rpi4 p4d: Time drift is -16 seconds
Feb 18 13:58:21 rpi4 p4d: Time drift is -16 seconds
Feb 18 14:00:31 rpi4 p4d: Time drift is -16 seconds
Feb 18 14:02:41 rpi4 p4d: Time drift is -17 seconds
Feb 18 14:04:51 rpi4 p4d: Time drift is -17 seconds
Feb 18 14:07:01 rpi4 p4d: Time drift is -17 seconds
Feb 18 14:09:11 rpi4 p4d: Time drift is -17 seconds
Feb 18 14:11:21 rpi4 p4d: Time drift is -17 seconds
Feb 18 14:13:31 rpi4 p4d: Time drift is -17 seconds
Feb 18 14:15:41 rpi4 p4d: Time drift is -17 seconds
Feb 18 14:17:51 rpi4 p4d: Time drift is -17 seconds
Feb 18 14:20:01 rpi4 p4d: Time drift is -17 seconds
Feb 18 14:22:11 rpi4 p4d: Time drift is -17 seconds
Feb 18 14:24:21 rpi4 p4d: Time drift is -17 seconds
Feb 18 14:26:31 rpi4 p4d: Time drift is -17 seconds
Feb 18 14:28:41 rpi4 p4d: Time drift is -17 seconds
Feb 18 14:30:51 rpi4 p4d: Time drift is -17 seconds
Feb 18 14:33:01 rpi4 p4d: Time drift is -17 secondsWas hat es mit diesem Time drift alle 130 Sekunden auf sich?
Mein Intervall der Aufzeichnung liegt bei 120 Sekunden.
Ein paar weitere Fragen bleiben noch:
Im Reiter "Setup - IO Setup" habe ich in der Tabelle zwei Schalter. Ist dieses Verständnis so richtig?
Bei meinem MQTT Server kommen noch ein paar topics an, mit denen ich so gerade nichts anfangen kann:
p4d2mqtt/ping
p4d2mqtt/changes
p4d2mqtt//stateFeb 18 15:40:16 rpi4 p4d: -> (p4d2mqtt/ping)[{"ping" : true, "sender" : "p4d"}]
Feb 18 15:40:16 rpi4 p4d: <- (p4d2mqtt/ping) [{"ping" : true, "sender" : "p4d"}] retained 0
Feb 18 15:40:21 rpi4 p4d: -> (p4d2mqtt/Anlagenstatus/state)[{"Status": {"value": "Heizen"}}]
Feb 18 15:40:21 rpi4 p4d: -> (p4d2mqtt/changes)[{"id": "UD:0x01", "type": "UD", "name": "Heizungsstatus", "unit": "zst", "state": "off", "value": 3.0, "action": "CHANGE"}]
Feb 18 15:40:31 rpi4 p4d: -> (p4d2mqtt/Anlagenstatus/state)[{"Status": {"value": "Heizen"}}]
Feb 18 15:40:31 rpi4 p4d: -> (p4d2mqtt/changes)[{"id": "UD:0x01", "type": "UD", "name": "Heizungsstatus", "unit": "zst", "state": "off", "value": 3.0, "action": "CHANGE"}]
Feb 18 15:40:41 rpi4 p4d: -> (p4d2mqtt/Anlagenstatus/state)[{"Status": {"value": "Heizen"}}]
Feb 18 15:40:41 rpi4 p4d: -> (p4d2mqtt/changes)[{"id": "UD:0x01", "type": "UD", "name": "Heizungsstatus", "unit": "zst", "state": "off", "value": 3.0, "action": "CHANGE"}]
Feb 18 15:40:47 rpi4 p4d: -> (p4d2mqtt/ping)[{"ping" : true, "sender" : "p4d"}]
Feb 18 15:40:47 rpi4 p4d: <- (p4d2mqtt/ping) [{"ping" : true, "sender" : "p4d"}] retained 0
Feb 18 15:40:51 rpi4 p4d: -> (p4d2mqtt/Anlagenstatus/state)[{"Status": {"value": "Heizen"}}]
Feb 18 15:40:51 rpi4 p4d: -> (p4d2mqtt/changes)[{"id": "UD:0x01", "type": "UD", "name": "Heizungsstatus", "unit": "zst", "state": "off", "value": 3.0, "action": "CHANGE"}]
Feb 18 15:41:01 rpi4 p4d: -> (p4d2mqtt/Anlagenstatus/state)[{"Status": {"value": "Heizen"}}]
Feb 18 15:41:01 rpi4 p4d: -> (p4d2mqtt/changes)[{"id": "UD:0x01", "type": "UD", "name": "Heizungsstatus", "unit": "zst", "state": "off", "value": 3.0, "action": "CHANGE"}]
Feb 18 15:41:11 rpi4 p4d: -> (p4d2mqtt/Anlagenstatus/state)[{"Status": {"value": "Heizen"}}]
Feb 18 15:41:11 rpi4 p4d: -> (p4d2mqtt/changes)[{"id": "UD:0x01", "type": "UD", "name": "Heizungsstatus", "unit": "zst", "state": "off", "value": 3.0, "action": "CHANGE"}]
Feb 18 15:41:18 rpi4 p4d: -> (p4d2mqtt/ping)[{"ping" : true, "sender" : "p4d"}]
Feb 18 15:41:18 rpi4 p4d: <- (p4d2mqtt/ping) [{"ping" : true, "sender" : "p4d"}] retained 0
Feb 18 15:41:21 rpi4 p4d: -> (p4d2mqtt/Anlagenstatus/state)[{"Status": {"value": "Heizen"}}]
Feb 18 15:41:21 rpi4 p4d: -> (p4d2mqtt/changes)[{"id": "UD:0x01", "type": "UD", "name": "Heizungsstatus", "unit": "zst", "state": "off", "value": 3.0, "action": "CHANGE"}]
Feb 18 15:41:31 rpi4 p4d: -> (p4d2mqtt/Anlagenstatus/state)[{"Status": {"value": "Heizen"}}]
Feb 18 15:41:31 rpi4 p4d: -> (p4d2mqtt/changes)[{"id": "UD:0x01", "type": "UD", "name": "Heizungsstatus", "unit": "zst", "state": "off", "value": 3.0, "action": "CHANGE"}]
Feb 18 15:41:41 rpi4 p4d: -> (p4d2mqtt/Anlagenstatus/state)[{"Status": {"value": "Heizen"}}]
Feb 18 15:41:41 rpi4 p4d: -> (p4d2mqtt/changes)[{"id": "UD:0x01", "type": "UD", "name": "Heizungsstatus", "unit": "zst", "state": "off", "value": 3.0, "action": "CHANGE"}]Ich verstehe den Sinn darin nicht. Erleuchte mich bitte.
Ein topic für den Menüpunkt "Fehler" wäre nicht schlecht. Keine Ahnung, ob das überhaupt so mit MQTT geht, da ja immer nur der letzte Fehler übertragen werden dürfte und diese dann von der Hausautomatisierung geloggt werden müssten, so dass ich mich bei einem Fehler von meiner Hausautomatisierung darüber informieren lassen könnte, bspw. per WhatsApp/Telegram oder Alexa erzählt mir, dass an der Heizung ein Fehler vorliegt oder was auch immer...
-------------------
Ich hoffe, du verstehst meine Nachricht nicht falsch! Ich meckere nicht.
Im Zusammenspiel mit MQTT ist das wirklich eine runde Sache geworden! Alle Hausautomatisierungen (FHEM, openHAB, HomeAssistant, etc.) funktionieren anscheinend in Bezug auf MQTT etwas anders, was zumindest bei mir immer wieder zu Fragen oder Änderungswünschen führt. Ich hoffe, ich bin dir wegen meiner Hartnäckigkeit nicht lästig.
Alles in allem gefällt mir wirklich, wie du das Projekt weiter entwickelt hast. Es gibt immer irgendwo etwas neues zu entdecken! Das neue Dashboard finde ich richtig klasse/gelungen. Endlich kann man sich anhand gruppierbarer Widgets einen Überblick über verschiedene Baugruppen verschaffen. Das hatte ich vor 1-2 Jahren auch mal so am Beispiel Kodi bei dir angefragt. Nun ist es in ähnlicher Form vorhanden. Wirklich perfekt!
Ich bin allerdings noch nicht dahinter gestiegen, wie ich mehrere Reiter/Seiten/Gruppen im Dashboard erstelle. Ich habe das bisher nur hier auf dem ersten Screenshot hier gesehen (Heizung Kessel Puffer Heizkreis):
Vielleicht kann mich da auch nochmal jemand kurz erleuchten. Wie geht das?
Vielen, vielen Dank nochmal!
Schönes Wochenende schonmal vorab!
Gruß Hoppel
es läuft nun laut Anzeige im WebIf die Version 0.9.3?
vor der reconnect Meldung kommt weiter hin No update from MQTT since '%s', disconnect from MQTT to force recover ?
Die zweite Frage kann ich auch mit Ja beantworten. Die MQTT Logs hatte ich ca. um 17:50 deaktiviert, hier das Logfile:
Gruß Hoppel
Moin Karlheinz,
ich war ehrlich gesagt auch erstaunt, dass ich vorhin gar keinen Meckerbeitrag in diesem Forum gefunden habe, dass der Tapatalk Support eingestellt wurde. 😃
Wahrscheinlich haben mittlerweile alle mit Tapatalk abgeschlossen.
Wäre toll, wenn das mit WSC-Connect klappt!
Viele Grüße Hoppel
OK, ich melde mich später. Mein kleiner Sohn will nun erstmal was von seinem Papa haben.
Hallo Leute,
vor einiger Zeit gab es hier eine Tapatalk Integration, die ich wie in vielen anderen Foren auch sehr gern genutzt habe. Mittlerweile gibt es bei den deutschen Foren aber fast nirgendwo mehr Tapatalk.
Wie dem auch sei... Dieses Forum verwendet die WoltLab Suite. Da gibt es ein Plugin, dass so ähnlich wie Tapatalk funktioniert nur werden die Foren und User Daten hier nicht mit externen Providern gesynct bzw. ausgetauscht.
Es gibt Apps für Android und für iOS. Hier ist es zu finden:
Mittlerweile sind dort einige Foren vertreten, die ich auch nutze. Hier eine Übersicht aller Foren, die das Plugin nutzen:
Wäre cool, wenn Ihr euch das für das Holzheizer Forum auch mal anschauen könntet.
Danke und Gruß Hoppel
Es hat keine Eile, mach wie es bei dir passt.
Ich habe den Thread jetzt im Blick. Nachdem Tapatalk hier im Forum deaktiviert wurde, habe ich keine Infos mehr zu Updates in diesem Thread erhalten. Ich habe aber jetzt erstmal Push Mail aktiviert.
Viele Grüße Hoppel
Danke erstmal für die zügige Bereitstellung eines potentiellen Fixes. Leider bleiben die Reconnect Meldungen aber nach dem Update bestehen.
Brauchst du noch weitere Logs?
Gruß Hoppel
