Hallo Zusammen,
ich habe eine Frage zum Einbinden eines CC2531 Zigbee Sticks. Ich habe bereits Mosquito auf dem Pi laufen und über MQTT Sonoff-S20 Steckdosen in Betrieb.
Nun würde ich gerne den CC2531 Zigbee Sticks auch einbinden. Ich lese nun verschiedene Angaben bzgl Installation. Was muss ich genau machen?
- geht beides parallel? Port 1883 ist durch MQTT bereits belegt. Habe einen MQTT2-Server mal angelegt, der bleibt aber auf 'MQTT2_FHEM_Server initilized'
- Muss ich Mosquito rausschmeißen, einen MQTT2-Server aufsetzen mit Port 1883 und alle bisherigen MQTT Gerät mit MQTT2 neu verbinden?
Wer kann mich aufs richtige Pferd setzen?
Zitatgeht beides parallel?
Klar, mit unterschiedlichen Ports "beliebig" viele.
ZitatMuss ich Mosquito rausschmeißen, einen MQTT2-Server aufsetzen mit Port 1883 und alle bisherigen MQTT Gerät mit MQTT2 neu verbinden?
Also muessen muss man gar nichts, siehe https://wiki.fhem.de/wiki/MQTT#MQTT2
Aber ich wuerde MQTT2_SERVER empfehlen, da es vieles vereinfacht. Falls man mosquitto stoppt, und 1883 auf dem gleichen Server von MQTT2_SERVER bedient wird, dann muss man an den Endgeraeten nichts aendern. Dieser Server kann auch von anderen "MQTT-Empfaenger" verwendet werden, genauso wie mosquitto, "nur" die FHEM-interne Anbindung wird einfacher.
Wenn in FHEM MQTT und MQTT_DEVICE Instanzen definiert wurden, dann sind diese alle hinfaellig, und durch MQTT2_DEVICE zu ersetzen.
Vielleicht noch eine Anmerkung:
Die "minimalinvasive" Methode dürfte die sein, erst mal den MQTT2_CLIENT zu nutzen, da aber dann das Attribut "subscriptions" zu nutzen und das auf den zigbee-Topic zu beschränken.
Dann sollte es "ungefährlich" sein, autocreate am 2-er Client anzuschalten (simple reicht hier).
Bitte dann nur darauf achten, bei dem zigbee-Brückengerät eine andere CID zu verwenden als gerade die des MQTTT2_CLIENT (Kopie vom autocreate-Gerät erstellen, analog https://wiki.fhem.de/wiki/MQTT2_CLIENT#Anwendung zum GeneralBridge-template).
Wäre nett, wenn du das austesten könntest; so kannst du ggf. auch einfach deine weiteren Geräte nacheinander auf MQTT2_DEVICE umstellen, (wenn du das magst), und mußt nicht gleich alle anfassen...
Sind alle "auf MQtt2_DEVICE", kannst du zum Schluß den mosquitto durch MQTT2_SERVER ersetzen.
Danke Euch, habe es gestern Abend noch geschafft. Bin aber noch nicht ganz glücklich.
Hatte im MQTTT2_CLIENT nicht auf subscriptions gefiltert und autocreate auf complex.
Somit wurden auch die Sonoff gefunden und angelegt, jedoch alle in einem device.
Hier mal ein list vom MQTTT2_CLIENT, nun aber mit subscriptions und autocreate simple.
Internals:
BUF
CFGFN
DEF 127.0.0.1:1883
DeviceName 127.0.0.1:1883
FD 53
FUUID 5c928aee-f33f-2776-fa39-8e88f34400008e36
NAME MQTT_via_mosquitto
NR 3429
PARTIAL
STATE opened
TYPE MQTT2_CLIENT
WBCallback
clientId MQTTviamosquitto
lastMsgTime 1553152332.52074
nextOpenDelay 5
READINGS:
2019-03-21 08:10:12 state opened
Attributes:
DbLogExclude .*
autocreate simple
disable 0
room MQTT,MQTT2_DEVICE
subscriptions zigbee
Du kannst das auch nachträglich noch umstellen mit simple und den subscriptions...
Würde jetzt: CLIENT umstellen und zwei Kopien des vorhandenen Devices ("Sammeldevice") machen.
Eine bekommt eine für die zigbee-Bridge passende CID (das kann ein Phantasiewert sein!), die andere eine andere CID. Auf die erste wendest du das zigbee-Bridge-Template an, auf das andere die "00_General-Bridge".
_DANACH_ kannst du die readingList vom "Sammeldevice" löschen und deine ganzen zigbee-Geräte sollten nach und nach erstellt werden.... Wenn nicht, "save" nicht vergessen und ggf. den CLIENT nochmal "anfassen", dass der seine subscriptions abruft (alternativ: einen restart von FHEM durchführen).
ZitatSomit wurden auch die Sonoff gefunden und angelegt, jedoch alle in einem device.
Das ist normal bei MQTT2_CLIENT, da es nicht ueber clientId verfuegt. Hier ist autocreate nur mit einem bridgeRegexp sinnvoll.
MQTT2_SERVER kann Geraete genau trennen, und fuer jedes ein eigenes MQTT2_DEVICE anlegen.
Dafuer kann man nicht Schrittweise umstellen.
Ich muss Euch noch einmal belästigen...
Ich glaube ich werde von MQTT auf MQTT2 umstellen.
Gibt es dafür eine kleine Anleitung welche Schritte in welcher Reihenfolge nötig oder best-practices sind?
Muss man alle Devices neu anlegen und alte löschen? Das heißt auch alle DOIFs usw müssen angepasst werden?
Gibt es eine einfache Migration?
danke Euch
"Anleitung"? Hmm, na ja....
Also hier (https://forum.fhem.de/index.php/topic,98882.0.html) habe ich neulich mal jemandem geholfen, von TASMOTA_DEVICE nach MQTT2_DEVICE umzustellen.
Bitte erst den ganzen Thread lesen und dann v.a. auch die daraus entstandenen aktuellen Fassungen der Einführung zu den Praxisbeispielen im Wiki (und ggf. zu MQTT2_CLIENT).
Die Umstellung scheint in dem konkreten Fall kein größeres Problem gewesen zu sein, aber ob und wie umfassend ggf. der Nacharbeitsbedarf ist, kommt sehr auf die Eventhandler (notify/DOIF etc.) an. Insbesondere: Die attrTemplates stellen von Groß-auf Kleinschriebung für on/off um.
Ansonsten wird sowieso meistens JSON ausgepackt, und da ist das Ergebnis in der Regel gleich (wenn auch die Device-Namen dann nach der Umstellung den bisherigen entsprechen).
Hallo Zusammen,
da die Abende wieder dunkler werden wollte ich das Thema für mich noch einmal angehen und von MQTT auf MQTT2 umstellen.
Habe mir nun folgende Schritte dafür notiert.
Backup erstellen
Mosquito stoppen (port 1883)
- sudo service mosquitto stop
DOIFs sichern für Sonoff Steckdosen
DOIFs deaktivieren für Sonoff Steckdosen
Bisherige MQTT devices löschen
- MQTT device
- 5 Sonoff Geräte mit Tasmota
In Tasmota Geräten das MQTT 'full topic' wieder zu default Wert ändern
%prefix%/%topic% (Aus <https://github.com/arendst/Tasmota/wiki/MQTT-Overview> )
MQTT2 server anlegen (port 1883)
define MQTT2_SERVER MQTT2_SERVER 1883
Neue MQTT2 devices sollten automatisch angelegt werden
Wenn erfolgreich Mosquito von Pi deinstallieren, oder zumindest autostart deaktivieren
Habe ich etwas vergessen oder übersehe ich etwas?
Danke Euch!
Würde das so sehen:
Backup erstellen
Mosquito stoppen (port 1883)
- sudo service mosquitto stop
DOIFs sichern für Sonoff Steckdosen
DOIFs deaktivieren für Sonoff Steckdosen
Bisherige MQTT devices löschen
- MQTT device
- 5 Sonoff Geräte mit Tasmota
In Tasmota Geräten das MQTT 'full topic' wieder zu default Wert ändern
%prefix%/%topic% (Aus <https://github.com/arendst/Tasmota/wiki/MQTT-Overview> )
MQTT2 server anlegen (port 1883)
define MQTT2_SERVER MQTT2_SERVER 1883
Neue MQTT2 devices sollten automatisch angelegt werden - die ESP's müssen aber ggf. neu gestartet werden...
Jeweils passendes attrTemplate wählen und anwenden
Wenn erfolgreich Mosquito von Pi deinstallieren (autostart deaktivieren geht notfalls auch, aber sowas vergißt man gerne, und dann reaktiviert sich das zur Unzeit...)
Hinweise:
- Die DOIF reagieren evtl. einfach nicht mehr, wenn nicht mehr passende Events kommen (wg. Kleinschreibung, z.B.). Die müssen/können dann einfach angepaßt werden.
- autocreate setzt voraus, dass Daten kommen, was uU. im laufenden Betrieb nicht passiert.
Gruß und viel Erfolg, Beta-User
beim define fehlte das global...
auch muss wohl das system autocreate ebenfalls aktiv sein, nicht nur im MQTT2_Server...
Backup erstellen
Mosquito stoppen (port 1883)
- sudo service mosquitto stop
DOIFs sichern für Sonoff Steckdosen
DOIFs deaktivieren für Sonoff Steckdosen
Bisherige MQTT devices löschen
- MQTT device
- 5 Sonoff Geräte mit Tasmota
In Tasmota Geräten das MQTT 'full topic' wieder zu default Wert ändern
%prefix%/%topic% (Aus <https://github.com/arendst/Tasmota/wiki/MQTT-Overview> )
MQTT2 server anlegen (port 1883)
define MQTT2_SERVER MQTT2_SERVER 1883 global
Neue MQTT2 devices sollten automatisch angelegt werden - die ESP's müssen aber ggf. neu gestartet werden...
Jeweils passendes attrTemplate wählen und anwenden
Wenn erfolgreich Mosquito von Pi deinstallieren (autostart deaktivieren geht notfalls auch, aber sowas vergißt man gerne, und dann reaktiviert sich das zur Unzeit...)
kurzes Update zu den MQTT Settings in Tasmota für S20 und POW:
Die default Einstellungen für Full Topic haben keine Readings geliefert, erst nachdem ich wieder auf /SmartHome/Steckdosen/%topic%/%prefix%/ umgestellt habe kamen alle Readings an.
Vorab mal sorry wg. dem "global". Generell sollte man bei jedem define nochmal in die commandref sehen, solche Kochrezepte interpretiere ich eigentlich immer so, dass ich die Doku "danebenlege" und das dann so mache, wie die Doku sagt, das Kochrezept ist nur für die Stichworte.
Und dass autocreate auch als TYPE aktiv sein muß, steht auch in den Praxisbeispielen, es macht für mich nicht den Riesensinn, alles nochmal jedem einzeln zu schreiben (deswegen schreibt man doch solche Artikel, oder habe ich was verpaßt...?)
Was es mit den "Full Topic"-Problemen auf sich hat, kann ich nicht beurteilen, aber das klingt so, als wäre irgendwo noch was verbogen, kein Neustart erfolgt oä.. Eigentlich sollte es keinen Unterschied machen (die attrTemplates sollten andererseits aber sowieso auch die "Videoblog"-verbogenen Topicpfade erkennen).
So war das nicht gemeint, aber Leute die wie nach so was suchen sollen nicht auf falsche Infos stoßen, daher habe ich es noch einmal erwähnt.
Danke für die Hilfe.
Hallo Zusammen, ich stehe vor einen ähnlichen Problem.
Bis Dato wurde meine Umgebung auf MQTT (Mosquitto) realisiert.
Nun habe ich ein paar Shelly 2.5 für Rollanden und Dimmer installiert. Wenn man mehr als nur ein/ausschalten will (das geht) muss es wohl mqtt2 sein.
Ich machte ein Backup, deaktivierte den Mosquitto Dienst, löschte alle in der fhem config was damit zu tun hatte und führte folgende Befehl aus:
define MQTT2_SERVER MQTT2_SERVER 1883 global
danach blendeten sich alle Fhem Prozesse.
Den fehm Dienst kann ich natürlich neustarten aber die Änderung (Zeile) wurde nicht in die Config übernommen.
Mit einem anderen Port geht es, aber fhem öffnet auf dem Server kein TCP Port.
1883 ist aber auch nicht offen (netstat)
Geht heißt aber nicht das funktioniert, sondern das fhem nicht abstürzt.
Hat jemand eine Idee was ich vergessen habe könnte?
Fhem läuft auf einem Raspi 3 (Buster)
Gruß Sebastian
Zitatdefine MQTT2_SERVER MQTT2_SERVER 1883 global
danach blendeten sich alle Fhem Prozesse.
Diese Info reicht nicht fuer eine verlaessliche Analyse, dafuer braucht man ein FHEM-Log.
Ich rate:
- die Zeile wurde direkt in fhem.cfg eingetragen und gespeichert.
- das fuehrt ein rereadcfg aus was mit Neustart equivalent ist, und da 1883 schon belegt war (weil die Zeile doppelt in fhem.cfg drin ist?) hat sich FHEM beendet.
danke für die schnelle Antwort.
Nein, es wurde über die Komandozeile ausgeführt.
auf einen andern port kann ich mit dem mqtt explorer verbinden und empfange bzw sehen schaltbefehle.
clients also geräte können sich nicht verbinden. ich hab mein an tasmota gerät zu den test genommen weil man auf der Konsole mehr sieht.
es wurde ein logfile (aber leer, von dem Dimmer erzeugt)
ZitatUndefined subroutine &MQTT::DEVICE::client_attr called at ./FHEM/10_MQTT_DEVICE.pm line 232, <$fh> line 872.
Soweit ich sehe, ist das ein Bug in MQTT_DEVICE (und auch in MQTT_BRIDGE), und hat nichts zu tun mit MQTT2_SERVER, eigentlich ist dieses Problem ein Fall fuer den MQTT Maintainer.
Ich (als MQTT2_*.pm Maintainer) wuerde alle MQTT_DEVICE Definitionen entfernen, und danach auf MQTT2 umsteigen :)
Wie empfohlen hab ich alle alten mqtt Geräte aus der config gelöscht und diese gesichert.
die machte ich über die Webseite und kontrollierte mit nano ob nicht doch noch etwas drin ist.
es bleibt dabei, sobald auf Port 1883 gehen will fliegt mir alles um die Ohren.
Zitat von: rudolfkoenig am 10 Februar 2020, 21:06:22
Soweit ich sehe, ist das ein Bug in MQTT_DEVICE (und auch in MQTT_BRIDGE), und hat nichts zu tun mit MQTT2_SERVER, eigentlich ist dieses Problem ein Fall fuer den MQTT Maintainer.
Nicht wirklich. Wenn kein MQTT Device definiert ist, ist auch die Methode 'client_attr' nicht verfügbar. Daher funktionieren alle MQTT_DEVICE und MQTT_BRIDGE Geräte nicht mehr. Nicht wirklich schön gelöst (habe ich das von dem Ursprungsautor bereits so geerbt), ist aber auch kein wirklicher Fehler, zumindest soweit man die erwartete Vorgehensweise einhält.
Zitat von: Basti-K am 10 Februar 2020, 19:09:31
Nun habe ich ein paar Shelly 2.5 für Rollanden und Dimmer installiert. Wenn man mehr als nur ein/ausschalten will (das geht) muss es wohl mqtt2 sein.
Nur vollständigkeitshalber: Natürlich kann man mit alten MQTT-Modulen auch alles schalten/dimmen/positionieren, was man auch mit MQTT2 kann.
;)
"attr global verbose" steht leider auf 1 oder 2, damit sieht man nicht mehr, wer welche Ports oeffnen kann.
Bitte FHEM aus der Console mit "perl fhem.pl -d fhem.cfg" starten (wie auch hier (https://wiki.fhem.de/wiki/FHEM_startet_nicht_-_Tipps_zur_Fehlersuche#Neue_M.C3.B6glichkeit_des_Debuggen) beschrieben), weil Fehler, die zum Absturz von FHEM fuehren, FHEM selbst nicht mehr in die Log Datei schreiben kann.
Ansonsten schließe ich mich der Empfehlung an: alles alte restlos entfernen (und am besten auch etwas Ordnung im FHEM schaffen, die Log ist ja voller Fehlermeldungen) und Schritt nach Schritt die neuen Module einrichten. Falls irgendetwas den Port blockiert - den Übeltäter entfernen und den Linux ggf. neu starten (ist zwar normalerweise überflüssig, aber wer weiß...).
ich hab mal etwas ausprobiert:
/opt/fhem/FHEM/97_timerTS.pm
zeile 86 auskommentiert.
nun geht es (scheinbar, welche Auswirkungen meine Änderung hab kann ich noch nicht überblicken. (bin kein coder)
alle tasmotas haben sich gemeldet und der Dimmer liefert schon mal readings.
Latest Revision: 21166
File Rev Last Change
fhem.pl 21056 2020-01-26 13:01:53Z rudolfkoenig
90_at.pm 17561 2018-10-18 14:45:30Z rudolfkoenig
98_autocreate.pm 20791 2019-12-20 17:30:57Z rudolfkoenig
98_average.pm 16293 2018-02-28 21:33:57Z rudolfkoenig
10_CUL_HM.pm 21093 2020-02-02 13:51:56Z martinp876
98_dewpoint.pm 18846 2019-03-10 11:45:58Z hotbso
98_DOIF.pm 20929 2020-01-10 09:44:35Z Damian
98_dummy.pm 20665 2019-12-06 11:05:35Z rudolfkoenig
34_ESPEasy.pm 18608 2019-02-16 09:03:52Z dev0
91_eventTypes.pm 14888 2017-08-13 12:07:12Z rudolfkoenig
98_expandJSON.pm 17324 2018-09-11 06:48:31Z dev0
01_FHEMWEB.pm 20818 2019-12-23 20:12:15Z rudolfkoenig
92_FileLog.pm 20826 2019-12-25 19:06:07Z rudolfkoenig
# $Id: 31_fronthemDevice.pm 21 2015-02-13 20:25:09Z. herrmannj $
39_gassistant.pm 18283 2019-01-16 16:58:23Z justme1968
98_HMinfo.pm 20889 2020-01-05 07:01:32Z martinp876
10_IT.pm 20839 2019-12-28 09:41:47Z bjoernh
98_JsonList2.pm 20561 2019-11-22 19:59:14Z rudolfkoenig
10_MQTT2_DEVICE.pm 20964 2020-01-13 17:02:05Z rudolfkoenig
00_MQTT2_SERVER.pm 20451 2019-11-04 10:37:40Z rudolfkoenig
No Id found for 99_myUtils.pm
91_notify.pm 20827 2019-12-25 19:17:36Z rudolfkoenig
33_readingsGroup.pm 21151 2020-02-08 16:00:45Z justme1968
51_RPI_GPIO.pm 19785 2019-07-05 21:39:13Z klausw
14_SD_WS07.pm 19859 2019-07-19 18:20:22Z Sidey
00_SIGNALduino.pm 20746 2019-12-14 22:26:52Z Sidey
98_structure.pm 21131 2020-02-06 08:52:19Z rudolfkoenig
99_SUNRISE_EL.pm 18732 2019-02-25 13:15:34Z rudolfkoenig
98_SVG.pm 20950 2020-01-12 10:41:37Z rudolfkoenig
42_SYSMON.pm 17227 2018-08-29 19:58:18Z hexenmeister
98_telnet.pm 17529 2018-10-14 12:57:06Z rudolfkoenig
97_timerTS.pm 3 2018-03-04 00:00:00Z noansi
00_TSCUL.pm 49 2018-08-04 00:00:00Z noansi
99_Utils.pm 21112 2020-02-04 10:02:12Z rudolfkoenig
98_version.pm 15140 2017-09-26 09:20:09Z markusbloch
AttrTemplate.pm 20425 2019-10-30 08:33:31Z rudolfkoenig
Blocking.pm 17553 2018-10-17 15:56:35Z rudolfkoenig
Color.pm 20813 2019-12-22 18:42:10Z justme1968
CoProcess.pm 18425 2019-01-26 16:45:12Z justme1968
DevIo.pm 20174 2019-09-16 18:04:03Z rudolfkoenig
DevIoTS.pm 11 2018-01-20 00:00:00Z noansi
# $Id: fhconverter.pm 21 2015-02-13 20:25:09Z. herrmannj $
HMConfig.pm 20888 2020-01-05 06:59:29Z martinp876
HttpUtils.pm 20800 2019-12-22 09:13:49Z moises
RTypes.pm 10476 2016-01-12 21:03:33Z borisneubert
No Id found for SD_ProtocolData.pm
No Id found for SD_Protocols.pm
SetExtensions.pm 19208 2019-04-17 19:27:09Z rudolfkoenig
TcpServerUtils.pm 19138 2019-04-07 10:17:21Z rudolfkoenig
der Pi ist auch aktuell.