Hallo liebe Leute,
hatte heute Mittag etwa ein Update des Systems angestoßen. Heute Abend wundere ich mich, das wirklich nichts an Aufgaben ausgeführt wurde. ALso flux mal FHEM aufrufen... Nö... keine Verbindung zu FHEM möglich. Also habe ich mal in das LogFile geschaut:
Can't use an undefined value as a symbol reference at ./FHEM/93_RFHEM.pm line 81.
2016.10.11 20:36:36.793 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2016.10.11 20:36:36.793 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2016.10.11 20:36:36.798 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2016.10.11 20:36:36.813 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2016.10.11 20:36:36.843 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2016.10.11 20:36:36.853 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2016.10.11 20:36:37.825 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2016.10.11 20:36:39.749 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
Das war's dann auch schon :(
Die üblichen Hinweise, das Telnet nicht installiert sei, sind natürlich dummfug; ist da und funktioniert.
Frage ist also, wo ich hier anfangen muss zu suchen? Irgendwas muss ja bei im heutigen Debian- Update drin gewesen sein, was Telnet vermeintlich Rechte entzogen hat. Nur mit den Rechten unter Debian bin ich ein absoluter DAU und habe wirklich keinen Schimmer, was ich wo wie überprüfen muss, um FHEM wieder ans Laufen zu bringen.
Wäre super, wenn mir da mal wer zeitnah auf die Sprünge helfen könnte.
Das Problem hat mit telnet nichts zu tun.
Apropos telnet: funktioniert denn "telnet localhost 7072" vom FHEM-Server aus? Was heisst "FHEM aufrufen"?
Was steht am Anfang des logs? Ich meine sowas wie "2016.10.11 20:57:36 3: telnetPort: port 7072 opened"
... Telnet läuft auf dem Server. Ein Aufruf direkt auf dem Server generiert ...
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
Mit "Aufrufen" meine ich den Aufruf der GUI von einem x-beliebigen System aus über Port 8083-5, wobei der hier allseits beliebte Feuervogel stumpf ...
Firefox kann keine Verbindung zu dem Server unter xeon1:8083 aufbauen.
...meldet.
Am Anfang sieht alles normal aus, also ...
2016.10.11 21:05:09.187 1: Including fhem.cfg
2016.10.11 21:05:11.028 3: telnetPort: port 7072 opened
2016.10.11 21:05:11.557 3: WEB: port 8083 opened
2016.10.11 21:05:11.560 3: WEBphone: port 8084 opened
2016.10.11 21:05:11.561 3: WEBtablet: port 8085 opened
2016.10.11 21:05:11.562 3: geogps: port 9796 opened
....
Daher nehme ich ja auch an, das hier irgendwie direkt Systemrechte verbogen wurden, was ich natürlich nicht nachvollziehen kann; ohne Hilfe zumindest nicht ::)
Zitat von: M_I_B am 11 Oktober 2016, 20:50:45
Hallo liebe Leute,
hatte heute Mittag etwa ein Update des Systems angestoßen. Heute Abend wundere ich mich, das wirklich nichts an Aufgaben ausgeführt wurde. ALso flux mal FHEM aufrufen... Nö... keine Verbindung zu FHEM möglich. Also habe ich mal in das LogFile geschaut:
Can't use an undefined value as a symbol reference at ./FHEM/93_RFHEM.pm line 81.
2016.10.11 20:36:36.793 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2016.10.11 20:36:36.793 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2016.10.11 20:36:36.798 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2016.10.11 20:36:36.813 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2016.10.11 20:36:36.843 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2016.10.11 20:36:36.853 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2016.10.11 20:36:37.825 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
2016.10.11 20:36:39.749 1: BlockingInformParent (PRESENCE_ProcessLocalScan): Can't connect to localhost:7072: IO::Socket::INET: connect: Verbindungsaufbau abgelehnt
Das war's dann auch schon :(
Die üblichen Hinweise, das Telnet nicht installiert sei, sind natürlich dummfug; ist da und funktioniert.
Frage ist also, wo ich hier anfangen muss zu suchen? Irgendwas muss ja bei im heutigen Debian- Update drin gewesen sein, was Telnet vermeintlich Rechte entzogen hat. Nur mit den Rechten unter Debian bin ich ein absoluter DAU und habe wirklich keinen Schimmer, was ich wo wie überprüfen muss, um FHEM wieder ans Laufen zu bringen.
Wäre super, wenn mir da mal wer zeitnah auf die Sprünge helfen könnte.
Anfangen zu suchen? Ich fange immer damit an ob der Prozess aktiv ist und ob die Ports geöffnet sind. wenn ich weiss wo ich zu suchen beginnen soll, probiere ich mal AEG (ausschalten, einschalten, geht). Ich mache nach einem update auch immer sofort shutdown restart und beobachte dabei die logdatei. Keine Ahnung was du davon schon probiert hast.
Du schreibst zu beginn ist alles normal (21:05), die Fehlermeldungen sind von 20:36.
Verwirrt ich bin
Bin etwas ratlos. Kannst du ein "lsof -p <FHEM-Pid>" Ausgabe anhaengen, wobei FHEM-Pid am Anfang des Logs steht. Oder per PS feststellbar ist.
... dann entwirre ich dich mal ;D
Mit Update ist das OS gemeint. Das FHEM- Update lief vorher vollkommen problemlos.
Für das OS- Update habe ich mir ein Script geschrieben, welches den Server nach erfolgreichem Update neu startet.
Das alles lief wie gesagt irgendwann heute umzu Middach. Da das OS- Update offensichtlich keine Fehler generiert hat, habe ich von dem nicht startenden FHEM bis heute Abend nichts mitbekommen.
Die Zeiten des Logfiles sind daher korrekt, da ich erst kurz vor diesem Zeitpunkt Kenntnis vom stehenden FHEM erhalten habe, den Dienst selbst versucht habe neu zu starten, den Server dann neu gestartet und... von dem eitpunkt ist der Log- Auszug...
@rudolfkoenig: versuche ich mal... moment ...
Die FHEM PID ist aktuell 999 (mal gut das nicht 666 ::) )
Ich habe per SSH dann also "lsof -p 999" eingegeben... nix. Keinerlei Ausgabe
BTW: Willst du selber mal drauf zugreifen? Dann mache ich mal einen Port nach außen auf; dann aber per PN o.ä. ...
EDIT:
FHEM per SSH angehalten, Logfile weggesichert und gelöscht, Server neu gestartet, logfile angeschaut... Und nun tauchen die telnet- Fehler gar nicht mehr auf. Es erscheint lediglich noch die Fehlermeldung ...
2016.10.11 23:10:20.382 3: CUL_HM set HM1RM3 statusRequest
2016.10.11 23:10:21.386 3: CUL_HM set HM2DI1_1 statusRequest
2016.10.11 23:10:22.390 3: CUL_HM set HM2DI1_2 statusRequest
2016.10.11 23:10:23.394 3: CUL_HM set HM2SD1_1 statusRequest
2016.10.11 23:10:48.463 3: Wetter: 0 result(s) retrieved
Can't use an undefined value as a symbol reference at ./FHEM/93_RFHEM.pm line 81.
... und danach nun nichts mehr ... Komische Sache. Denn vorher kamen ja noch reichlich Fehler mit Telnet hinterher...
Zitat von: M_I_B am 11 Oktober 2016, 22:21:29
... dann entwirre ich dich mal ;D
Mit Update ist das OS gemeint. Das FHEM- Update lief vorher vollkommen problemlos.
Für das OS- Update habe ich mir ein Script geschrieben, welches den Server nach erfolgreichem Update neu startet.
Das alles lief wie gesagt irgendwann heute umzu Middach. Da das OS- Update offensichtlich keine Fehler generiert hat, habe ich von dem nicht startenden FHEM bis heute Abend nichts mitbekommen.
Die Zeiten des Logfiles sind daher korrekt, da ich erst kurz vor diesem Zeitpunkt Kenntnis vom stehenden FHEM erhalten habe, den Dienst selbst versucht habe neu zu starten, den Server dann neu gestartet und... von dem eitpunkt ist der Log- Auszug...
Ahja, sorry das kommt davon wenn man drei Sachen gleichzeitig macht.
Das Phänomen das du beschreibst kenne ich, das passiert bei mir auch ab und zu, bei mir wird dann ein child process blockiert, leider habe ich die Ursache noch nicht herausgefunden, seitdem ich versucht habe alle blockierenden Abfragen auf eine andere Instanz auszulagern, tritt es kaum mehr auf.
Sent from my iPad using Tapatalk
... tja, nichts zu wollen >:(
Ich habe dann mal ein Backup von vor drei Tagen zurück gespielt (HD- Image). Nun ist alles wieder schön. Ich werde heute Nacht noch mal einen Versuch unternehmen, erst FHEM und danach das OS auf aktuellen Stand zu bringen. Mal sehen, ob der gleiche Fehler erneut auftaucht.
seitdem ich versucht habe alle blockierenden Abfragen auf eine andere Instanz auszulagern
Wie macht man so was? Ich (und sicherlich viele Andere mit ähnlicher Konfig) habe hier z.B. das Problem, das alle per Ser2Net (oder SoCat oder was auch immer) verbundenen Slave- Systeme beim FHEM- Start in Betrieb und erreichbar sein müssen. Ist auch nur einer mal eben weggetreten, kommt FHEM nicht aus'm Knick, da unendlich auf die Verbindung gewartet wird.
Kann man so etwas nicht irgendwie umgehen? Denn wenn ich z.B. nicht im Haus bin und mal ein Netzausfall so lange andauert, das auch die UPS das nicht überbrücken können, benötigen die Systeme natürlich bei Netzwiederkehr unterschiedlich lange beim Booten; es ist kaum kalkulierbar, wer zuerst den Hintern oben hat...
Hallo,
also das Problem mit diesen Abhängigkeiten habe ich so nicht, da würde ich aber im startscript entsprechende Wartezeiten oder checks einbauen.
Ich habe ein paar Satelliten Raspis, ein CB und auch auf der Synology eine FHEM Instanz, teils um neue Sachen auszuprobieren oder auch um vom zentralen FHEM einfach verschiedene Dinge zu steuern, das ist alles historisch gewachsen. Diese FHEM's connecten alle zum Mosquitto Server, d.h. die Kommunkiation basiert nur auf MQTT, mit Ausnahme von tts. Auf dem zentralen Gerät habe ich vier FHEM Instanzen, eben ein Test-und Entwicklungssystem, eine Demoinstanz, eine "mach alles was blockieren könnte Instanz" und mein zentrales FHEM. root@HAL9000:/opt/fhem# ps -ef |grep fhem
fhem 1048 1 0 Sep25 ? 00:05:44 perl fhem.pl demo_fhem.cfg
fhem 1568 1 0 Sep25 ? 02:40:40 perl fhem.pl 2_fhem.cfg
root 1983 10956 0 14:36 pts/2 00:00:00 grep fhem
fhem 18015 1 0 Oct09 ? 00:35:09 /usr/bin/perl fhem.pl dev_fhem.cfg
fhem 26192 1 18 Oct11 ? 02:44:40 perl fhem.pl fhem.cfg
alles was blockeiren ist oder sein könnte (soweit ich es erkennen konnte) wird von FHEM2 (oder noch von der Entwicklungsinstanz, da gibts einige longrunning Prototypen) ausgeführt und über ein MQQTDevice im zentralen FHEM dargestellt, angefangen hat das vor langer Zeit mit einem Problem mit 1-wire Server der mir dauernd mein FHEM blockiert hat, mittlerweile funktioniert das ja.
I/O Devices die auch senden sind entweder sowieso Netzwerkdevices oder sonst am zentralen Gerät angesteckt.
Bei reinem Empfängern bzw. Datenlieferanten wie z.B. das OWL Energiemessgerät reicht das das MQTT publishen völlig. Kling jetzt zwar ziemlich kompliziert, funktioniert aber, vor allem da das eine ewige Baustelle ist, sehr gut.
... ganz ehrlich? Ich versteh nur "Bahnhof Kofferklau'n?" ::)
Was ist MQTT ? Noch nie gehört...
Wie gesagt bin ich auf Ser2Net resp. SoCat angewiesen. Der RPi z.B., der zeitnah die komplette Heizungssteuerung (primär, also Brenner, Pumpen, Speicher, ...) übernehmen soll, ist erst mal grundsätzlich autark und hat auch eine eigene UPS (alles Eigenbau; mit'm Lötkolben kann ich um...). Dennoch erhält Dieser von der Hauptinstanz natürlich Informationen, z.B. vom Präsenz- Modul, Umweltdaten, Arbeit-, Feier- und Feriendaten, Weckzeiten, e.t.c. Ebenso meldet der HeizungsPI natürlich auch Stati zurück, im GAU- Fall z.B. Druckabfall (Leck), Brennerstörung, Ölstand Tanks, ...
Ich wüsste jetzt nicht, wie ich das anders realisieren könnte. Und leider sind offensichtlich all diese Module, welche zwei oder mehr Systeme miteinander verbinden können, nicht wirklich blockadefrei...
Automatisiertes Update per eigenscript ..... bist Du sicher, das es sauber durchlief?
Aber mal für eventuelle folgende Fehlersuche:
https://forum.fhem.de/index.php/topic,54271.msg467373.html#msg467373 (https://forum.fhem.de/index.php/topic,54271.msg467373.html#msg467373)
... jo, da bin ich ziemlich sicher. In keinem Logfile war irgend was von einem Fehler nach dem Zeitpunkt zu finden.
Wir werden heute Nacht mal sehen, was passiert. Da sicher ich der Übersichtlichkeit wegen mal alle Logfiles weg und lösche die Alten, bevor ich einen neuen Versuch starte. Dann findet man (ich) besser durch, falls was faul ist; ich werde berichten...
Inzwischen läuft es ja wieder mit dem zurück gespielten Backup. Das werde ich heute aber vorher noch mal per Hand anstoßen... besser is das ;)
Zitat von: M_I_B am 12 Oktober 2016, 15:18:20
... ganz ehrlich? Ich versteh nur "Bahnhof Kofferklau'n?" ::)
Was ist MQTT ? Noch nie gehört...
Schau mal in der Referenz anch, da sind die enstprechenden FHEM Komponent gut beschrieben, mosquitto kannst auf Debian/Raspian einfach mit apt-get install mosquitto installieren, ich weiss jetzt nicht mehr auswendig ob man die clients extra installieren muss.
Sehr vereinfacht schiebt ein Client (publish) eine Information in einen Messagebus (Topic und Payload) den ein anderer client (subscribed) lesen kann.
Dh. du brauchst beim publishen nur den Topictree und den Inhalt übergeben und das kommt dann beim jedem client der auf dieses Topic subscribed hat, an.
Ich habe z.b. einen Luftdrucksensor, dieser Wert wird gepublisht und in jeder FHEM Instnaz kann ich den verwenden. Oder z.b. habe ich viele OLED/LCD's Displays die auf unterschiedlichste Arten angesprochen werden (eben historisch gewachsen), die Werte dafür kommen von unterschiedlichen FHEM's und werden an der für den Output verantwortlichem FHEM via MQTT subscribe angefragt. Also z.b. Luftdruck bzw. Wetterwerte von yahoo, Temperaturwert vom Pool und pH Wert vom Poolcontroller usw. zu Displayinhalt zusammengestellt und ausgegeben, u.U. auch mit MQTT.
Mosquitto ist der MQTT Server den ich auf meinen DebianServern verwende. Da keine direkte Kommunkation zwischen den FHEM's und anderen MQTT Clients besteht, gibt es auch keine Blockaden, der einzige single point of failure ist halt der zentrale mosquitto. Aber der läuft auf dem zentralen System und wenn der weg ist, dann ist es auch egal wenns keinen mosquitto gibt. Hatte für mich einen riesigen Vorteil, ich hole z.B verschieden Informationen von externen Webseiten (oder Kalender), allerdings nur sehr sporadisch wie z.b. die Wettervorhersage, die ändert sich nicht alle 10 min. Mit FHEM2FHEM bekam ich bei Neustart dieses Device in der zentralen Instanz erst befüllt wenn es denn nächsten Update gibt, mit MQTT bekomm ich sofort den letzten bekannten Stand.
ZitatIch wüsste jetzt nicht, wie ich das anders realisieren könnte. Und leider sind offensichtlich all diese Module, welche zwei oder mehr Systeme miteinander verbinden können, nicht wirklich blockadefrei...
Genau das war für mich der Grund MQTT einzusetzen, und natürlich das ich damit bestehende und zukünftige Plattformen oder Sensoren sehr einfach einbinden kann, wie NodeRed, ESPeasy (bevor es das FHEM Modul gab) meine ehemaliges OPENHAB oder was auch immer da kommen wird.
Also kein socat, FHEM2FHEM oder sonstigen Dinge mehr bei mir. Einzig tts nutze ich noch remote, aber auch nur weil es einfach funktniert und ich noch viele andere Projekt habe, die wichtiger sind.
... ok, erst mal vielen, lieben Dank für die ausführliche Erklärung!
Ich hoffe mal, das ich das jetzt richtig verstanden habe und versuche es mal mit meinen Worten...
Ich installiere auf dem Server (ist ein Xeon, auf dem auch die FHEM- Hauptinstanz läuft) den Mosquito- Server, auf allen anderen Slave- Systemen den Mosquito- Client. Nun übermittle ich nicht mehr per Ser2Net o.ä., sondern teile dem "Stechviech" mit, was für die Slaves bestimmt ist und die Client holen sich dann alles, wenn's für sie bestimmt ist ? So in etwa?
Hast du mal'n Link für DAU's?
das triffts ganz gut,
hier ein paar links:
https://github.com/mqtt/mqtt.github.io/wiki (https://github.com/mqtt/mqtt.github.io/wiki)
auf jedem FHEM benötigtst du eine MQTT Instanz, quasi den FHEM mosquitto client, das ist das I/O Device für die MQTT Devices und MQTT Bridgeshttp://fhem.de/commandref.html#MQTT (http://fhem.de/commandref.html#MQTT)
Eine MQTT Brigde mapped die definierten Readings zu einem MQTT Topic (publish) http://fhem.de/commandref.html#MQTT_DEVICE (http://fhem.de/commandref.html#MQTT_DEVICE)
Beispiel:
Internals:
DEF POOLCONTROL
IODev MQTT
NAME MQ_poolcontroller
NOTIFYDEV POOLCONTROL
NR 164
NTFY_ORDER 50-MQ_poolcontroller
STATE outgoing publish sent
TYPE MQTT_BRIDGE
qos 0
retain 0
Readings:
2016-10-12 17:27:18 transmission-state outgoing publish sent
Message_ids:
Publishreadings:
PC_Channel_10_Name /POOLCONTROL/PC_Channel_10_Name
PC_Channel_10_Unit /POOLCONTROL/PC_Channel_10_Unit
PC_Channel_10_Value /POOLCONTROL/PC_Channel_10_Value
PC_Channel_11_Name /POOLCONTROL/PC_Channel_11_Name
PC_Channel_11_Unit /POOLCONTROL/PC_Channel_11_Unit
PC_Channel_11_Value /POOLCONTROL/PC_Channel_11_Value
PC_Channel_12_Name /POOLCONTROL/PC_Channel_12_Name
PC_Channel_12_Unit /POOLCONTROL/PC_Channel_12_Unit
PC_Channel_12_Value /POOLCONTROL/PC_Channel_12_Value
PC_Channel_13_Name /POOLCONTROL/PC_Channel_13_Name
PC_Channel_13_Unit /POOLCONTROL/PC_Channel_13_Unit
PC_Channel_13_Value /POOLCONTROL/PC_Channel_13_Value
PC_Channel_14_Name /POOLCONTROL/PC_Channel_14_Name
PC_Channel_14_Unit /POOLCONTROL/PC_Channel_14_Unit
PC_Channel_14_Value /POOLCONTROL/PC_Channel_14_Value
PC_Channel_15_Name /POOLCONTROL/PC_Channel_15_Name
PC_Channel_15_Unit /POOLCONTROL/PC_Channel_15_Unit
PC_Channel_15_Value /POOLCONTROL/PC_Channel_15_Value
PC_Channel_16_Name /POOLCONTROL/PC_Channel_16_Name
PC_Channel_16_mode /POOLCONTROL/PC_Channel_16_mode
PC_Channel_16_state /POOLCONTROL/PC_Channel_16_state
PC_Channel_17_Name /POOLCONTROL/PC_Channel_17_Name
PC_Channel_17_mode /POOLCONTROL/PC_Channel_17_mode
PC_Channel_17_state /POOLCONTROL/PC_Channel_17_state
PC_Channel_18_Name /POOLCONTROL/PC_Channel_18_Name
PC_Channel_18_mode /POOLCONTROL/PC_Channel_18_mode
PC_Channel_18_state /POOLCONTROL/PC_Channel_18_state
PC_Channel_19_Name /POOLCONTROL/PC_Channel_19_Name
PC_Channel_19_mode /POOLCONTROL/PC_Channel_19_mode
PC_Channel_19_state /POOLCONTROL/PC_Channel_19_state
PC_Channel_1_Name /POOLCONTROL/PC_Channel_1_Name
PC_Channel_1_Unit /POOLCONTROL/PC_Channel_1_Unit
PC_Channel_1_Value /POOLCONTROL/PC_Channel_1_Value
PC_Channel_20_Name /POOLCONTROL/PC_Channel_20_Name
PC_Channel_20_mode /POOLCONTROL/PC_Channel_20_mode
PC_Channel_20_state /POOLCONTROL/PC_Channel_20_state
PC_Channel_21_Name /POOLCONTROL/PC_Channel_21_Name
PC_Channel_21_mode /POOLCONTROL/PC_Channel_21_mode
PC_Channel_21_state /POOLCONTROL/PC_Channel_21_state
PC_Channel_22_Name /POOLCONTROL/PC_Channel_22_Name
PC_Channel_22_mode /POOLCONTROL/PC_Channel_22_mode
PC_Channel_22_state /POOLCONTROL/PC_Channel_22_state
PC_Channel_23_Name /POOLCONTROL/PC_Channel_23_Name
PC_Channel_23_mode /POOLCONTROL/PC_Channel_23_mode
PC_Channel_23_state /POOLCONTROL/PC_Channel_23_state
PC_Channel_24_Name /POOLCONTROL/PC_Channel_24_Name
PC_Channel_24_Unit /POOLCONTROL/PC_Channel_24_Unit
PC_Channel_24_Value /POOLCONTROL/PC_Channel_24_Value
PC_Channel_25_Name /POOLCONTROL/PC_Channel_25_Name
PC_Channel_25_state /POOLCONTROL/PC_Channel_25_state
PC_Channel_26_Name /POOLCONTROL/PC_Channel_26_Name
PC_Channel_26_state /POOLCONTROL/PC_Channel_26_state
PC_Channel_27_Name /POOLCONTROL/PC_Channel_27_Name
PC_Channel_27_state /POOLCONTROL/PC_Channel_27_state
PC_Channel_2_Name /POOLCONTROL/PC_Channel_2_Name
PC_Channel_2_Unit /POOLCONTROL/PC_Channel_2_Unit
PC_Channel_2_Value /POOLCONTROL/PC_Channel_2_Value
PC_Channel_36_Name /POOLCONTROL/PC_Channel_36_Name
PC_Channel_36_Unit /POOLCONTROL/PC_Channel_36_Unit
PC_Channel_36_Value /POOLCONTROL/PC_Channel_36_Value
PC_Channel_37_Name /POOLCONTROL/PC_Channel_37_Name
PC_Channel_37_Unit /POOLCONTROL/PC_Channel_37_Unit
PC_Channel_37_Value /POOLCONTROL/PC_Channel_37_Value
PC_Channel_38_Name /POOLCONTROL/PC_Channel_38_Name
PC_Channel_38_Unit /POOLCONTROL/PC_Channel_38_Unit
PC_Channel_38_Value /POOLCONTROL/PC_Channel_38_Value
PC_Channel_3_Name /POOLCONTROL/PC_Channel_3_Name
PC_Channel_3_Unit /POOLCONTROL/PC_Channel_3_Unit
PC_Channel_3_Value /POOLCONTROL/PC_Channel_3_Value
PC_Channel_4_Name /POOLCONTROL/PC_Channel_4_Name
PC_Channel_4_Unit /POOLCONTROL/PC_Channel_4_Unit
PC_Channel_4_Value /POOLCONTROL/PC_Channel_4_Value
PC_Channel_5_Name /POOLCONTROL/PC_Channel_5_Name
PC_Channel_5_Unit /POOLCONTROL/PC_Channel_5_Unit
PC_Channel_5_Value /POOLCONTROL/PC_Channel_5_Value
PC_Channel_6_Name /POOLCONTROL/PC_Channel_6_Name
PC_Channel_6_Unit /POOLCONTROL/PC_Channel_6_Unit
PC_Channel_6_Value /POOLCONTROL/PC_Channel_6_Value
PC_Channel_7_Name /POOLCONTROL/PC_Channel_7_Name
PC_Channel_7_Unit /POOLCONTROL/PC_Channel_7_Unit
PC_Channel_7_Value /POOLCONTROL/PC_Channel_7_Value
PC_Channel_8_Name /POOLCONTROL/PC_Channel_8_Name
PC_Channel_8_Unit /POOLCONTROL/PC_Channel_8_Unit
PC_Channel_8_Value /POOLCONTROL/PC_Channel_8_Value
PC_Channel_9_Name /POOLCONTROL/PC_Channel_9_Name
PC_Channel_9_Unit /POOLCONTROL/PC_Channel_9_Unit
PC_Channel_9_Value /POOLCONTROL/PC_Channel_9_Value
VWC /POOLCONTROL/VWC
state /POOLCONTROL/state
subscribe:
subscribeExpr:
Attributes:
IODev MQTT
publishReading_PC_Channel_10_Name /POOLCONTROL/PC_Channel_10_Name
publishReading_PC_Channel_10_Unit /POOLCONTROL/PC_Channel_10_Unit
publishReading_PC_Channel_10_Value /POOLCONTROL/PC_Channel_10_Value
publishReading_PC_Channel_11_Name /POOLCONTROL/PC_Channel_11_Name
publishReading_PC_Channel_11_Unit /POOLCONTROL/PC_Channel_11_Unit
publishReading_PC_Channel_11_Value /POOLCONTROL/PC_Channel_11_Value
publishReading_PC_Channel_12_Name /POOLCONTROL/PC_Channel_12_Name
publishReading_PC_Channel_12_Unit /POOLCONTROL/PC_Channel_12_Unit
publishReading_PC_Channel_12_Value /POOLCONTROL/PC_Channel_12_Value
publishReading_PC_Channel_13_Name /POOLCONTROL/PC_Channel_13_Name
publishReading_PC_Channel_13_Unit /POOLCONTROL/PC_Channel_13_Unit
publishReading_PC_Channel_13_Value /POOLCONTROL/PC_Channel_13_Value
publishReading_PC_Channel_14_Name /POOLCONTROL/PC_Channel_14_Name
publishReading_PC_Channel_14_Unit /POOLCONTROL/PC_Channel_14_Unit
publishReading_PC_Channel_14_Value /POOLCONTROL/PC_Channel_14_Value
publishReading_PC_Channel_15_Name /POOLCONTROL/PC_Channel_15_Name
publishReading_PC_Channel_15_Unit /POOLCONTROL/PC_Channel_15_Unit
publishReading_PC_Channel_15_Value /POOLCONTROL/PC_Channel_15_Value
publishReading_PC_Channel_16_Name /POOLCONTROL/PC_Channel_16_Name
publishReading_PC_Channel_16_mode /POOLCONTROL/PC_Channel_16_mode
publishReading_PC_Channel_16_state /POOLCONTROL/PC_Channel_16_state
publishReading_PC_Channel_17_Name /POOLCONTROL/PC_Channel_17_Name
publishReading_PC_Channel_17_mode /POOLCONTROL/PC_Channel_17_mode
publishReading_PC_Channel_17_state /POOLCONTROL/PC_Channel_17_state
publishReading_PC_Channel_18_Name /POOLCONTROL/PC_Channel_18_Name
publishReading_PC_Channel_18_mode /POOLCONTROL/PC_Channel_18_mode
publishReading_PC_Channel_18_state /POOLCONTROL/PC_Channel_18_state
publishReading_PC_Channel_19_Name /POOLCONTROL/PC_Channel_19_Name
publishReading_PC_Channel_19_mode /POOLCONTROL/PC_Channel_19_mode
publishReading_PC_Channel_19_state /POOLCONTROL/PC_Channel_19_state
publishReading_PC_Channel_1_Name /POOLCONTROL/PC_Channel_1_Name
publishReading_PC_Channel_1_Unit /POOLCONTROL/PC_Channel_1_Unit
publishReading_PC_Channel_1_Value /POOLCONTROL/PC_Channel_1_Value
publishReading_PC_Channel_20_Name /POOLCONTROL/PC_Channel_20_Name
publishReading_PC_Channel_20_mode /POOLCONTROL/PC_Channel_20_mode
publishReading_PC_Channel_20_state /POOLCONTROL/PC_Channel_20_state
publishReading_PC_Channel_21_Name /POOLCONTROL/PC_Channel_21_Name
publishReading_PC_Channel_21_mode /POOLCONTROL/PC_Channel_21_mode
publishReading_PC_Channel_21_state /POOLCONTROL/PC_Channel_21_state
publishReading_PC_Channel_22_Name /POOLCONTROL/PC_Channel_22_Name
publishReading_PC_Channel_22_mode /POOLCONTROL/PC_Channel_22_mode
publishReading_PC_Channel_22_state /POOLCONTROL/PC_Channel_22_state
publishReading_PC_Channel_23_Name /POOLCONTROL/PC_Channel_23_Name
publishReading_PC_Channel_23_mode /POOLCONTROL/PC_Channel_23_mode
publishReading_PC_Channel_23_state /POOLCONTROL/PC_Channel_23_state
publishReading_PC_Channel_24_Name /POOLCONTROL/PC_Channel_24_Name
publishReading_PC_Channel_24_Unit /POOLCONTROL/PC_Channel_24_Unit
publishReading_PC_Channel_24_Value /POOLCONTROL/PC_Channel_24_Value
publishReading_PC_Channel_25_Name /POOLCONTROL/PC_Channel_25_Name
publishReading_PC_Channel_25_state /POOLCONTROL/PC_Channel_25_state
publishReading_PC_Channel_26_Name /POOLCONTROL/PC_Channel_26_Name
publishReading_PC_Channel_26_state /POOLCONTROL/PC_Channel_26_state
publishReading_PC_Channel_27_Name /POOLCONTROL/PC_Channel_27_Name
publishReading_PC_Channel_27_state /POOLCONTROL/PC_Channel_27_state
publishReading_PC_Channel_2_Name /POOLCONTROL/PC_Channel_2_Name
publishReading_PC_Channel_2_Unit /POOLCONTROL/PC_Channel_2_Unit
publishReading_PC_Channel_2_Value /POOLCONTROL/PC_Channel_2_Value
publishReading_PC_Channel_36_Name /POOLCONTROL/PC_Channel_36_Name
publishReading_PC_Channel_36_Unit /POOLCONTROL/PC_Channel_36_Unit
publishReading_PC_Channel_36_Value /POOLCONTROL/PC_Channel_36_Value
publishReading_PC_Channel_37_Name /POOLCONTROL/PC_Channel_37_Name
publishReading_PC_Channel_37_Unit /POOLCONTROL/PC_Channel_37_Unit
publishReading_PC_Channel_37_Value /POOLCONTROL/PC_Channel_37_Value
publishReading_PC_Channel_38_Name /POOLCONTROL/PC_Channel_38_Name
publishReading_PC_Channel_38_Unit /POOLCONTROL/PC_Channel_38_Unit
publishReading_PC_Channel_38_Value /POOLCONTROL/PC_Channel_38_Value
publishReading_PC_Channel_3_Name /POOLCONTROL/PC_Channel_3_Name
publishReading_PC_Channel_3_Unit /POOLCONTROL/PC_Channel_3_Unit
publishReading_PC_Channel_3_Value /POOLCONTROL/PC_Channel_3_Value
publishReading_PC_Channel_4_Name /POOLCONTROL/PC_Channel_4_Name
publishReading_PC_Channel_4_Unit /POOLCONTROL/PC_Channel_4_Unit
publishReading_PC_Channel_4_Value /POOLCONTROL/PC_Channel_4_Value
publishReading_PC_Channel_5_Name /POOLCONTROL/PC_Channel_5_Name
publishReading_PC_Channel_5_Unit /POOLCONTROL/PC_Channel_5_Unit
publishReading_PC_Channel_5_Value /POOLCONTROL/PC_Channel_5_Value
publishReading_PC_Channel_6_Name /POOLCONTROL/PC_Channel_6_Name
publishReading_PC_Channel_6_Unit /POOLCONTROL/PC_Channel_6_Unit
publishReading_PC_Channel_6_Value /POOLCONTROL/PC_Channel_6_Value
publishReading_PC_Channel_7_Name /POOLCONTROL/PC_Channel_7_Name
publishReading_PC_Channel_7_Unit /POOLCONTROL/PC_Channel_7_Unit
publishReading_PC_Channel_7_Value /POOLCONTROL/PC_Channel_7_Value
publishReading_PC_Channel_8_Name /POOLCONTROL/PC_Channel_8_Name
publishReading_PC_Channel_8_Unit /POOLCONTROL/PC_Channel_8_Unit
publishReading_PC_Channel_8_Value /POOLCONTROL/PC_Channel_8_Value
publishReading_PC_Channel_9_Name /POOLCONTROL/PC_Channel_9_Name
publishReading_PC_Channel_9_Unit /POOLCONTROL/PC_Channel_9_Unit
publishReading_PC_Channel_9_Value /POOLCONTROL/PC_Channel_9_Value
publishReading_VWC /POOLCONTROL/VWC
publishReading_state /POOLCONTROL/state
room MQTT
stateFormat transmission-state
auf FHEM 2:
POOLCONTROL ist das FHEM device, MQ_poolcontroller ist MQTT Bridge. Ändert sich beim POOLCONTROL das reading VWC dann wird der Wert als Payload mit der Topic /POOLCONTROL/VWC gepublisht
zentrales FHEM:
dort gibt es das MQTT_DEVICE myPoolcontroller
Internals:
IODev MQTT
NAME myPoolcontroller
NR 2567
STATE Pooltemperatur: 15.69 °C <br> pH 7.20 Redox: 771.12 mV <br> Pumpe: auto on <br> Druck: 363.58 mBar Durchfluss: 4.33 cm/s
TYPE MQTT_DEVICE
qos 0
retain 0
Readings:
2016-10-12 17:32:34 BodenF 68
2016-10-12 17:32:34 PC_Channel_10_Value 33.00
2016-10-12 17:30:31 PC_Channel_11_Value 13.44
2016-10-12 17:28:22 PC_Channel_12_Value 127.94
2016-10-12 17:28:22 PC_Channel_13_Value 0.00
2016-10-12 17:28:22 PC_Channel_14_Value 0.00
2016-10-12 17:28:22 PC_Channel_15_Value 0.00
2016-10-12 17:28:23 PC_Channel_16_mode auto
2016-10-12 17:24:10 PC_Channel_16_state on
2016-10-12 17:28:23 PC_Channel_17_mode auto
2016-10-12 17:25:16 PC_Channel_17_state off
2016-10-12 17:28:23 PC_Channel_18_mode auto
2016-10-12 17:27:19 PC_Channel_18_state off
2016-10-12 17:28:23 PC_Channel_19_mode manu
2016-10-12 17:28:23 PC_Channel_19_state off
2016-10-12 17:32:33 PC_Channel_1_Value 1096.88
2016-10-12 17:28:23 PC_Channel_20_mode auto
2016-10-12 17:28:23 PC_Channel_20_state off
2016-10-12 17:28:24 PC_Channel_21_mode auto
2016-10-12 17:28:23 PC_Channel_21_state off
2016-10-12 17:28:24 PC_Channel_22_mode auto
2016-10-12 17:28:24 PC_Channel_22_state off
2016-10-12 17:28:24 PC_Channel_23_mode auto
2016-10-12 17:28:24 PC_Channel_23_state off
2016-10-12 17:32:34 PC_Channel_24_Value 4.33
2016-10-12 17:28:24 PC_Channel_25_state off
2016-10-12 17:28:24 PC_Channel_26_state off
2016-10-12 17:28:25 PC_Channel_27_state off
2016-10-12 17:30:30 PC_Channel_2_Value 2881.88
2016-10-12 17:20:02 PC_Channel_36_Value 35.00
2016-10-12 17:29:26 PC_Channel_37_Value 30.00
2016-10-12 17:28:25 PC_Channel_38_Value 100.00
2016-10-12 17:31:30 PC_Channel_3_Value 363.58
2016-10-12 17:32:33 PC_Channel_4_Value 1955.56
2016-10-12 17:30:30 PC_Channel_5_Value 46.05
2016-10-12 17:32:33 PC_Channel_6_Value 771.12
2016-10-12 17:27:19 PC_Channel_7_Value 7.20
2016-10-12 17:32:34 PC_Channel_8_Value 15.69
2016-10-12 17:29:25 PC_Channel_9_Value 12.19
2016-10-12 17:27:18 VWC 68
2016-10-12 17:32:34 transmission-state incoming publish received
Message_ids:
Sets:
subscribe:
/POOLCONTROL/+
/POOLCONTROL/PC_Channel_10_Value
/POOLCONTROL/PC_Channel_11_Value
/POOLCONTROL/PC_Channel_12_Value
/POOLCONTROL/PC_Channel_13_Value
/POOLCONTROL/PC_Channel_14_Value
/POOLCONTROL/PC_Channel_15_Value
/POOLCONTROL/PC_Channel_16_mode
/POOLCONTROL/PC_Channel_16_state
/POOLCONTROL/PC_Channel_17_mode
/POOLCONTROL/PC_Channel_17_state
/POOLCONTROL/PC_Channel_18_mode
/POOLCONTROL/PC_Channel_18_state
/POOLCONTROL/PC_Channel_19_mode
/POOLCONTROL/PC_Channel_19_state
/POOLCONTROL/PC_Channel_1_Value
/POOLCONTROL/PC_Channel_20_mode
/POOLCONTROL/PC_Channel_20_state
/POOLCONTROL/PC_Channel_21_mode
/POOLCONTROL/PC_Channel_21_state
/POOLCONTROL/PC_Channel_22_mode
/POOLCONTROL/PC_Channel_22_state
/POOLCONTROL/PC_Channel_23_mode
/POOLCONTROL/PC_Channel_23_state
/POOLCONTROL/PC_Channel_24_Value
/POOLCONTROL/PC_Channel_25_state
/POOLCONTROL/PC_Channel_26_state
/POOLCONTROL/PC_Channel_27_state
/POOLCONTROL/PC_Channel_2_Value
/POOLCONTROL/PC_Channel_36_Value
/POOLCONTROL/PC_Channel_37_Value
/POOLCONTROL/PC_Channel_38_Value
/POOLCONTROL/PC_Channel_3_Value
/POOLCONTROL/PC_Channel_4_Value
/POOLCONTROL/PC_Channel_5_Value
/POOLCONTROL/PC_Channel_6_Value
/POOLCONTROL/PC_Channel_7_Value
/POOLCONTROL/PC_Channel_8_Value
/POOLCONTROL/PC_Channel_9_Value
/POOLCONTROL/VWC
subscribeExpr:
^\/POOLCONTROL\/([^/]+)$
^\/POOLCONTROL\/PC_Channel_10_Value$
^\/POOLCONTROL\/PC_Channel_11_Value$
^\/POOLCONTROL\/PC_Channel_12_Value$
^\/POOLCONTROL\/PC_Channel_13_Value$
^\/POOLCONTROL\/PC_Channel_14_Value$
^\/POOLCONTROL\/PC_Channel_15_Value$
^\/POOLCONTROL\/PC_Channel_16_mode$
^\/POOLCONTROL\/PC_Channel_16_state$
^\/POOLCONTROL\/PC_Channel_17_mode$
^\/POOLCONTROL\/PC_Channel_17_state$
^\/POOLCONTROL\/PC_Channel_18_mode$
^\/POOLCONTROL\/PC_Channel_18_state$
^\/POOLCONTROL\/PC_Channel_19_mode$
^\/POOLCONTROL\/PC_Channel_19_state$
^\/POOLCONTROL\/PC_Channel_1_Value$
^\/POOLCONTROL\/PC_Channel_20_mode$
^\/POOLCONTROL\/PC_Channel_20_state$
^\/POOLCONTROL\/PC_Channel_21_mode$
^\/POOLCONTROL\/PC_Channel_21_state$
^\/POOLCONTROL\/PC_Channel_22_mode$
^\/POOLCONTROL\/PC_Channel_22_state$
^\/POOLCONTROL\/PC_Channel_23_mode$
^\/POOLCONTROL\/PC_Channel_23_state$
^\/POOLCONTROL\/PC_Channel_24_Value$
^\/POOLCONTROL\/PC_Channel_25_state$
^\/POOLCONTROL\/PC_Channel_26_state$
^\/POOLCONTROL\/PC_Channel_27_state$
^\/POOLCONTROL\/PC_Channel_2_Value$
^\/POOLCONTROL\/PC_Channel_36_Value$
^\/POOLCONTROL\/PC_Channel_37_Value$
^\/POOLCONTROL\/PC_Channel_38_Value$
^\/POOLCONTROL\/PC_Channel_3_Value$
^\/POOLCONTROL\/PC_Channel_4_Value$
^\/POOLCONTROL\/PC_Channel_5_Value$
^\/POOLCONTROL\/PC_Channel_6_Value$
^\/POOLCONTROL\/PC_Channel_7_Value$
^\/POOLCONTROL\/PC_Channel_8_Value$
^\/POOLCONTROL\/PC_Channel_9_Value$
^\/POOLCONTROL\/VWC$
Subscribereadings:
/POOLCONTROL/PC_Channel_10_Value PC_Channel_10_Value
/POOLCONTROL/PC_Channel_11_Value PC_Channel_11_Value
/POOLCONTROL/PC_Channel_12_Value PC_Channel_12_Value
/POOLCONTROL/PC_Channel_13_Value PC_Channel_13_Value
/POOLCONTROL/PC_Channel_14_Value PC_Channel_14_Value
/POOLCONTROL/PC_Channel_15_Value PC_Channel_15_Value
/POOLCONTROL/PC_Channel_16_mode PC_Channel_16_mode
/POOLCONTROL/PC_Channel_16_state PC_Channel_16_state
/POOLCONTROL/PC_Channel_17_mode PC_Channel_17_mode
/POOLCONTROL/PC_Channel_17_state PC_Channel_17_state
/POOLCONTROL/PC_Channel_18_mode PC_Channel_18_mode
/POOLCONTROL/PC_Channel_18_state PC_Channel_18_state
/POOLCONTROL/PC_Channel_19_mode PC_Channel_19_mode
/POOLCONTROL/PC_Channel_19_state PC_Channel_19_state
/POOLCONTROL/PC_Channel_1_Value PC_Channel_1_Value
/POOLCONTROL/PC_Channel_20_mode PC_Channel_20_mode
/POOLCONTROL/PC_Channel_20_state PC_Channel_20_state
/POOLCONTROL/PC_Channel_21_mode PC_Channel_21_mode
/POOLCONTROL/PC_Channel_21_state PC_Channel_21_state
/POOLCONTROL/PC_Channel_22_mode PC_Channel_22_mode
/POOLCONTROL/PC_Channel_22_state PC_Channel_22_state
/POOLCONTROL/PC_Channel_23_mode PC_Channel_23_mode
/POOLCONTROL/PC_Channel_23_state PC_Channel_23_state
/POOLCONTROL/PC_Channel_24_Value PC_Channel_24_Value
/POOLCONTROL/PC_Channel_25_state PC_Channel_25_state
/POOLCONTROL/PC_Channel_26_state PC_Channel_26_state
/POOLCONTROL/PC_Channel_27_state PC_Channel_27_state
/POOLCONTROL/PC_Channel_2_Value PC_Channel_2_Value
/POOLCONTROL/PC_Channel_36_Value PC_Channel_36_Value
/POOLCONTROL/PC_Channel_37_Value PC_Channel_37_Value
/POOLCONTROL/PC_Channel_38_Value PC_Channel_38_Value
/POOLCONTROL/PC_Channel_3_Value PC_Channel_3_Value
/POOLCONTROL/PC_Channel_4_Value PC_Channel_4_Value
/POOLCONTROL/PC_Channel_5_Value PC_Channel_5_Value
/POOLCONTROL/PC_Channel_6_Value PC_Channel_6_Value
/POOLCONTROL/PC_Channel_7_Value PC_Channel_7_Value
/POOLCONTROL/PC_Channel_8_Value PC_Channel_8_Value
/POOLCONTROL/PC_Channel_9_Value PC_Channel_9_Value
/POOLCONTROL/VWC VWC
Attributes:
IODev MQTT
autoSubscribeReadings /POOLCONTROL/+
room Pool
stateFormat Pooltemperatur: PC_Channel_8_Value °C <br> pH PC_Channel_7_Value Redox: PC_Channel_6_Value mV <br> Pumpe: PC_Channel_16_mode PC_Channel_16_state <br> Druck: PC_Channel_3_Value mBar Durchfluss: PC_Channel_24_Value cm/s
subscribeReading_PC_Channel_10_Value /POOLCONTROL/PC_Channel_10_Value
subscribeReading_PC_Channel_11_Value /POOLCONTROL/PC_Channel_11_Value
subscribeReading_PC_Channel_12_Value /POOLCONTROL/PC_Channel_12_Value
subscribeReading_PC_Channel_13_Value /POOLCONTROL/PC_Channel_13_Value
subscribeReading_PC_Channel_14_Value /POOLCONTROL/PC_Channel_14_Value
subscribeReading_PC_Channel_15_Value /POOLCONTROL/PC_Channel_15_Value
subscribeReading_PC_Channel_16_mode /POOLCONTROL/PC_Channel_16_mode
subscribeReading_PC_Channel_16_state /POOLCONTROL/PC_Channel_16_state
subscribeReading_PC_Channel_17_mode /POOLCONTROL/PC_Channel_17_mode
subscribeReading_PC_Channel_17_state /POOLCONTROL/PC_Channel_17_state
subscribeReading_PC_Channel_18_mode /POOLCONTROL/PC_Channel_18_mode
subscribeReading_PC_Channel_18_state /POOLCONTROL/PC_Channel_18_state
subscribeReading_PC_Channel_19_mode /POOLCONTROL/PC_Channel_19_mode
subscribeReading_PC_Channel_19_state /POOLCONTROL/PC_Channel_19_state
subscribeReading_PC_Channel_1_Value /POOLCONTROL/PC_Channel_1_Value
subscribeReading_PC_Channel_20_mode /POOLCONTROL/PC_Channel_20_mode
subscribeReading_PC_Channel_20_state /POOLCONTROL/PC_Channel_20_state
subscribeReading_PC_Channel_21_mode /POOLCONTROL/PC_Channel_21_mode
subscribeReading_PC_Channel_21_state /POOLCONTROL/PC_Channel_21_state
subscribeReading_PC_Channel_22_mode /POOLCONTROL/PC_Channel_22_mode
subscribeReading_PC_Channel_22_state /POOLCONTROL/PC_Channel_22_state
subscribeReading_PC_Channel_23_mode /POOLCONTROL/PC_Channel_23_mode
subscribeReading_PC_Channel_23_state /POOLCONTROL/PC_Channel_23_state
subscribeReading_PC_Channel_24_Value /POOLCONTROL/PC_Channel_24_Value
subscribeReading_PC_Channel_25_state /POOLCONTROL/PC_Channel_25_state
subscribeReading_PC_Channel_26_state /POOLCONTROL/PC_Channel_26_state
subscribeReading_PC_Channel_27_state /POOLCONTROL/PC_Channel_27_state
subscribeReading_PC_Channel_2_Value /POOLCONTROL/PC_Channel_2_Value
subscribeReading_PC_Channel_36_Value /POOLCONTROL/PC_Channel_36_Value
subscribeReading_PC_Channel_37_Value /POOLCONTROL/PC_Channel_37_Value
subscribeReading_PC_Channel_38_Value /POOLCONTROL/PC_Channel_38_Value
subscribeReading_PC_Channel_3_Value /POOLCONTROL/PC_Channel_3_Value
subscribeReading_PC_Channel_4_Value /POOLCONTROL/PC_Channel_4_Value
subscribeReading_PC_Channel_5_Value /POOLCONTROL/PC_Channel_5_Value
subscribeReading_PC_Channel_6_Value /POOLCONTROL/PC_Channel_6_Value
subscribeReading_PC_Channel_7_Value /POOLCONTROL/PC_Channel_7_Value
subscribeReading_PC_Channel_8_Value /POOLCONTROL/PC_Channel_8_Value
subscribeReading_PC_Channel_9_Value /POOLCONTROL/PC_Channel_9_Value
subscribeReading_VWC /POOLCONTROL/VWC
userReadings BodenF {calc_VWC(ReadingsVal("$name", "PC_Channel_2_Value",0))}
Dort habe ich wieder das attribut subscribeReading_VWC /POOLCONTROL/VWC also ein subscribe auf dieses Topic das mir ein Reading VWC mit dem akutuellen Wert erzeugt.
Darauf kann ich jetzt ein Logdevice und Grafiken definieren oder notifies auslösen. Ich kann auch den Poolcontroller in einzelne logische Devices "zerteilen" weil z.B. WVC eigentlich mit dem Pool nichts zu tun hat, aber weil ich den Messeingang frei hatte, messe ich damit die Bodenfeuchtigkeit für die Bewässerungssteuerng.
Was man sich vorher sehr gut überlegen sollte (habe ich natürlich nicht gemacht) wie man den Topic Tree, also die Hierarchie der Informationsstruktur aufbaut, als Beispiel /LAND/PLZ/ORT/STRASSE/HAUSNUMMER/TUERNUMMER/STOCK
jetzt kann ich mit einem client alle infos von /AT/2522/OWADO/HPTSTR/# oder nur von einem Wert /AT/2522/OWADO/HPTSTR/1/1/1 oder alles von /AT/# darstellen
Schaut jetzt sehr verwirrend aus und ist es auch, aber extrem flexibel und stabil, wenn ich jetzt so das vor mich hinschreibe überlege ich gerade ob ich das nicht dokumentieren sollte, wiel manchmal weiss ich gar nicht mehr wo die Daten "enstehen". Naja, das kann ich später auch noch machen
... also ... FHEM ist neu installiert, nachdem (!) das OS auf aktuellen Stand gebracht wurde. Nach zurückspielen der Konfig schien erst mal alles gut, auch wenn ich keinen Blassen habe, wo das Problem lag...
Aber eben gerade ist die Kiste wieder stehen geblieben... Also FHEM ist nicht mehr ansprechbar...
Bezeichnend für all diese Dinge ist immer folgender Logeintrag:
Can't use an undefined value as a symbol reference at ./FHEM/93_RFHEM.pm line 81.
Wenn man jetzt in diese Datei schaut, steht dort ...
81 print $socket $msg;
82 Log3 $name, 3, "Command executed";
83 #$socket->close();
84 #Log3 $name, 3, "Connection closed";}
Ich habe zwar keine Ahnung davon, aber ich vermute, das hier ein Kommando übers Netzwerk gesendet werden soll, was wiederum scheitert.
Interessant dabei ist allerdings, das alle verbundenen Rechner von dem System aus problemlos zu erreichen sind.
Da RFHEM nicht eingecheckt ist, kann dazu nicht sagen. Am besten den Autor direkt fragen.
... war ein bisschen busy mit meiner Heizungs- Steuerung, die heute als Prototyp vollständig in Betrieb gegangen ist (übernommen wurde nur die rein thermische OverTemp- Sicherung der alten Steuerung) so wie dem Zusammenbau und Einbinden von 15 HM-Heizkörperthermos und drei RaumThermos... puhhh ...
Ok, back to topic...
Ich denke, RFHEM wird mich auf Dauer immer ärgern, wie auch alle anderen, ähnlichen Teile, die FHEM bei Netzwerkproblemen ausbremsen. Somit ist es derzeit für mich sinnfrei, mich mit dem Modul- Autor auseinander zu setzen; der wird an dem grundsätzlichen Problem auch nichts ändern können.
Daher habe ich mich entschlossen, auf das von schka17 präferierte MQTT zu bauen, da sicherlich im Laufe der Zeit noch ein paar PI's hinzu kommen, und damit das Problem ja nicht geringer wird...
@schka17:
Würde es dir was ausmachen, mich mal über die ersten Hürden zu "sprechen", gerne auch über andere Kommunikationswege? Ich blick da nämlich immer noch nicht durch und da es bereits alles ein Live- System ist, möchte ich zumindest grobe Fehler vermeiden, die auf meinem noch bestehenden Unverständnis der Sache basieren ...
Ja, klar. Möchte aber nicht den Eindruck erwecken der Spezialist zu sein, aber meine Erfahrungen teile ich gerne, was den Kommunikationsweg betrifft bin ich flexibel
Hier gibts auch noch eine schöne Beschreibung https://forum.fhem.de/index.php/topic,36228.0/topicseen.html
Sent from my iPad using Tapatalk
... au ja! Die Beschreibung von Pf@nne ist ja ne Wucht! Das versteht sogar ein DAU wie ich ;)
Also werde ich wohl so tun:
Auf dem XEON mit der FHEM Hauptinstanz installiere ich Mosquito, richte dann auf dem Server und auf dem Heizungs-PI den Broker ein so wie jeweils eine MQTT_Bridge für jeden Status, den ich zum Server senden will und dort jeweils ein MQTT_Device passend zu der MQTT_Bridge, die das jeweilige Geplapper entgegen nimmt. Und da der Server auch an den Heizungs_PI was zu senden hat, das Ganze auch umgekehrt... Korrekt?
BTW: Kann (resp. könnte ich, wenn ich kann) darüber auch komplette Logdaten verlegen? Ich habe im Moment das gewollte Problem, das die 1wire- Sensoren u.a. Aktoren/Sensoren, eine immense Last auf dem kleinen PI generieren. Wenn ich dann aus diesen Logdaten auch noch schicke Plots mache, bleibt der fast stehen ^^ Außerdem wird das die SD- Karte nicht ewig mitmachen. Ich würde daher die generierten Logdateien gerne direkt auf dem Server ablegen und dort auch die Plots generieren. Frage ist halt, ob das über MQTT geht, oder doch z.B. das Mappen eines Netzwerk-LW's mehr Sinn macht, um den Ordner /log gleich auf den Server auszulagern...
Zitat von: M_I_B am 20 Oktober 2016, 15:28:55
... au ja! Die Beschreibung von Pf@nne ist ja ne Wucht! Das versteht sogar ein DAU wie ich ;)
Also werde ich wohl so tun:
Auf dem XEON mit der FHEM Hauptinstanz installiere ich Mosquito, richte dann auf dem Server und auf dem Heizungs-PI den Broker ein so wie jeweils eine MQTT_Bridge für jeden Status, den ich zum Server senden will und dort jeweils ein MQTT_Device passend zu der MQTT_Bridge, die das jeweilige Geplapper entgegen nimmt. Und da der Server auch an den Heizungs_PI was zu senden hat, das Ganze auch umgekehrt... Korrekt?
Ganz genau
Zitat
BTW: Kann (resp. könnte ich, wenn ich kann) darüber auch komplette Logdaten verlegen? Ich habe im Moment das gewollte Problem, das die 1wire- Sensoren u.a. Aktoren/Sensoren, eine immense Last auf dem kleinen PI generieren. Wenn ich dann aus diesen Logdaten auch noch schicke Plots mache, bleibt der fast stehen ^^ Außerdem wird das die SD- Karte nicht ewig mitmachen. Ich würde daher die generierten Logdateien gerne direkt auf dem Server ablegen und dort auch die Plots generieren. Frage ist halt, ob das über MQTT geht, oder doch z.B. das Mappen eines Netzwerk-LW's mehr Sinn macht, um den Ordner /log gleich auf den Server auszulagern...
Ich mach das mit dem Poolcontroller und anderen devices genauso, es gibt ein logdevice wo die MQTT_Device Events am zentralen Server geschrieben werden und eben auch die SVG's.
Mit Laufwerke mappen habe ich bei FHEM sehr schlechte Erfahrungen gemacht, bei Netzwerkfehlern oder Ausfällen der gemappten LW, oder auch externer DB's, dann steht das Ding, und auch nach Stromausfällen, alles in der richtigen reihenfolge starten, neinnein, der zentrale Server bzw. die zentrale Instanz verwendet lokale Resourcen und ist soweit wie möglich bzw. sinnvoll, autark. Habe zwar auch USV, aber ohne Strom und Netzwerk geht eh nichts mehr.
... ok, das mit den Log's schiebe ich erst mal auf, bis ich das hier am Laufen und halbwegs verstanden habe ^^
Also... Ich habe getan wie gesagt. Mosquitto läuft brav. Dann bei beiden MQTT gesetzt, uaf dem Server natürlich auf localhost, am Heizungs-PI auf den Server.
Dann habe ich versucht, die auf dem Server erfasste Außentemperatur an den HzPI zu übermitteln. Dazu habe ich ...
... auf dem Server:
define PUSH_temp_pi2 MQTT_DEVICE
attr PUSH_temp_pi2 IODev MQTT
attr PUSH_temp_pi2 publishSet temp /Heizung/temp/set
attr PUSH_temp_pi2 room MQTT
attr PUSH_temp_pi2 stateFormat state
attr PUSH_temp_pi2 subscribeReading_state /Heizung/temp
attr PUSH_temp_pi2 userReadings _state
... auf dem HzPI:
define PULL_temp_xeon MQTT_BRIDGE
attr PULL_temp_xeon IODev MQTT
attr PULL_temp_xeon publishState /Heizung/temp
attr PULL_temp_xeon room MQTT
attr PULL_temp_xeon stateFormat transmission-state
attr PULL_temp_xeon subscribeSet /Heizung/temp/set
... eingetragen.
Aber so oder so kommt da nur Murks bei raus... Ich nixe verstehen ???
Konkrete Frage:
Auf dem Server habe ich einen Dummy namens "TMP". In dem steht die aktuelle Außentemperatur, welcher bei jeder Änderung aktualisiert wird. Genau den Wert will ich auf den HzPI übertragen, wobei der Dummy dort "tmp_out" heißt...
... könntest du mal bitte schauen, wo ich was falsch gemacht habe? Denn mir ist im Moment nicht wirklich klar, wo ich Werte einfüllen muss und wo ich die Werte wieder heraus bekomme ...
probier mal auf dem Server
define PUSH_temp_pi2 MQTT_Device
attr PUSH_temp_pi2 IODev MQTT
attr PUSH_temp_pi2 room MQTT
attr PUSH_temp_pi2 publishSet 20 21 22 23 24 25 /Heizung/temp/set
attr PUSH_temp_pi2 stateFormat state
attr PUSH_temp_pi2 subscribeReading_state /Heizung/temp
attr PUSH_temp_pi2 userReadings _state
mit
mosquitto_sub -v -t "/Heizung/#"
siehst du dann die MQTT Messages
... nnnnnnöhhh :'(
Das mosquitto_sub -v -t "/Heizung/#" im Terminal, richtig? Da passiert nix. Ich kann aber sehr wohl mit z.B. mosquitto_pub -d -t /Heizung/temp -m "testit" aus einem zweiten Terminal eine Nachricht absetzen...
hmm, ich habs bei mir nachgebaut, da funktioniert es.
ich hab mal einen screenshot angehängt, vielleicht siehst du da irgendwo einen Unterschied zu deiner Konfiguration?
... nö, sieht bei mir genau so aus ???
EDIT: Na gugge mal da! Gerade noch mal probiert und nun kommen die Kommandos an...
Ok, das funktioniert also... Nun muss ich nur noch die Daten aus dem Dummy TMP irgendwie da rein bekommen...
deine readings sind schon unterschiedlich, hast du mal auf set gedrückt?
Sent from my iPad using Tapatalk
... mein EDIT hast du gesehen?
Also... Frage bleibt...
Ich muss ja nun irgendwie den Wert aus dem Dummy TMP publizieren. Ich habe jetzt diverse Versuche hinter mir, komme aber nicht drauf... Irgendwie muss das ja in die Zeile "attr PUSH_temp_pi2 publishSet [Inhalt von Dummy TMP] /Heizung/temp/set" rein... nur wie? Oder verstehe ich da irgend etwas vollkommen falsch? Wäre ja bei mir nix neues ::)
EDIT sagt: Ich habe Müll erzählt... Die zu übertragende Temperatur steht in TMP:Ta und nicht in TMP
Im Übrigen verwirrt mich die Aussage von "rretsiem" unter https://forum.fhem.de/index.php/topic,36228.0/topicseen.html Da schreibt er, das der Sender, also in meinem Fall der Server, der die Temperatur kennt und den Dummy TMP beherbergt, mit MQTT_BRIDGE anzulegen ist ?!?
Aus der Bezeichnung hätte ich das auch so verstanden, da ich ja eine "Brücke" vom Server zum HzPI bauen will...
Ok, für heute reicht's; zu müde, um noch was brauchbares produzieren zu können ...
edit hatte ich nicht gesehen,
ja, ich glaube da fehlt noch ein kleines Stück :-)
Wenn du Readings aus einem anderen Device, z.b. einem dummy, publishen willst, dann benötigst du eine MQTT_BRIDGE. MQTT_Device kannst du zum empfangen oder zum senden eines definierten Wertes, das was im PublishSet definiert ist,verwenden. Das ist sehr gut geeignet um etwas zu schalten, wie z.b. einen MQTT Aktor wie espEasy.
MIt der Definition von MQTT_BRIDGE gibts du auch dein Quell Device an und mit dem
attr publishReading_sourcereading /topictree/topic welches Reading auf welches topic gepublished wird.
in deinem Beispiel kannst du mit
set PUSH_temp_pi2 21 auch direkt den Wert setzen und gleichzeitig zum MQTT Broker pushen, allerdings nur Werte die du attr publishSet definiert hast.
Also wenn du einen Dummy als Steuerungselement im GUI verwenden willst dann definiere eine MQTT_BRIDGE
wenn dein Dummy TMP heisst
dann
define PUSH_temp_pi2 MQTT_BRIDGE TMP
attr PUSH_temp_pi2 publishReading_deinReading /Heizung/temp/set
... aha, so langsam komme ich dahinter! Danke für deine Geduld; ist (hier) nicht selbstverständlich ;)
Also...
Ich habe auf dem Server nun ...
define PUSH_temp_pi2 MQTT_BRIDGE TMP
attr PUSH_temp_pi2 IODev MQTT
attr PUSH_temp_pi2 publishReading_T1 /TMP/T1
attr PUSH_temp_pi2 publishReading_T2 /TMP/T2
attr PUSH_temp_pi2 publishReading_T3 /TMP/T3
attr PUSH_temp_pi2 publishReading_T4 /TMP/T4
attr PUSH_temp_pi2 publishReading_T5 /TMP/T5
attr PUSH_temp_pi2 publishReading_T6 /TMP/T6
attr PUSH_temp_pi2 publishReading_Ta /TMP/Ta
attr PUSH_temp_pi2 publishReading_state /TMP/state
attr PUSH_temp_pi2 stateFormat transmission-state
... auf dem HzPI ...
define PULL_temp_xeon MQTT_DEVICE TMP
attr PULL_temp_xeon IODev MQTT
attr PULL_temp_xeon room MQTT
attr PULL_temp_xeon subscribeReading_T1 /TMP/T1
attr PULL_temp_xeon subscribeReading_T2 /TMP/T2
attr PULL_temp_xeon subscribeReading_T3 /TMP/T3
attr PULL_temp_xeon subscribeReading_T4 /TMP/T4
attr PULL_temp_xeon subscribeReading_T5 /TMP/T5
attr PULL_temp_xeon subscribeReading_T6 /TMP/T6
attr PULL_temp_xeon subscribeReading_Ta /TMP/Ta
attr PULL_temp_xeon subscribeReading_state /TMP/state
... und siehe da: Alle meine Readings aus TMP vom Server sind nun bei der Heizung angekommen *FreudenTanz*
... jetzt kann ich zufrieden mal ein HeiaBubu machen ;)
Na dann gute nacht
Sent from my iPad using Tapatalk
... morgähn ...
... zu früh gefreut :(
Aus welchen Gründen auch immer kommt das Reading Ta und state nicht mit rüber. Beide sind korrekt auf beiden Seiten definiert und natürlich existierten die genau so auch im Dummy TMP (wurde ja auf Bridge- Seite mit get readings geholt). Auch werden sie im Broker erfasst und liegen also vor. Nur am Device kommten die nicht an...
... hmmm ... Konnte meinen vorhergehenden Beitrag nicht ergänzen ...
ZitatFehler beim Schreiben des Beitrages.
Textfeld wurde nicht ausgefüllt.
Na, dann so:
EDIT: Ich habe jetzt mal alle Tx- Readings auf beiden Seiten heraus genommen und nur Ta und state über gelassen. Nun kommt zwar Ta an (immerhin), aber state wird immer noch ignoriert.
Offensichtlich gibt es eine Mengenbegrenzung bezgl. der übertragbaren Readings? Und die Sache mit state kann ich mir gar nicht erklären... LIegt das an meinem Dummy selbst? Da ist doch nix spezielles dran?
define TMP dummy
attr TMP devStateIcon .*:noIcon
attr TMP readingList T1 T2 T3 T4 T5 T6 Ta
attr TMP room OD.Sensoren
Mengenbegrenzung halte ich für unwahrscheinlich, bei meinem poolcontroller habe ich mehr als 40 readings. Eine Vorraussetzung ist natürlich dass Events erzeugt werden, das kannst du mit dem eventmonitor überwachen. Überprüfe ob du bei setzen von Ta auch einen event bekommst. (Könnte jetzt nicht sagen warum nicht, aber Kontrolle ist besser)
Wo ich mir nicht ganz sicher bin ist state, das wird möglicherweise anders behandelt, es gibt dafür auch ein anderes attribut, ich glaube publishState. Sitze gerade nicht vor dem PC und kann nicht nachschauen.
das readingList kannte ich auch noch nicht, wieder was gelernt.
Mach bitte auch noch mal ein list von den drei devices.
Sent from my iPad using Tapatalk
Zitat von: schka17 am 21 Oktober 2016, 09:23:47... ist state, das wird möglicherweise anders behandelt, es gibt dafür auch ein anderes attribut, ich glaube publishState.
.... *GRRRRRR* Wie ich das hasse, wenn für im Grunde ein- und dieselbe Sache unterschiedliche Vorgehensweisen implementiert sind >:(
Danke für den zielführenden Hinweis! Genau das war es...