da ich einige Sonoff Schalter verwende hatte ich die bisher als MQTT_Device eingerichtet, dass funktioniert auf meinem Neu eingerichtetem Fhem gar nicht
Es kommt folgender Fehler
Cannot load module MQTT_DEVICE
Das Modul 10_MQTT_DEVICE.pm ist aber vorhanden in meiner Fhem Installation
wenn ich das mit MQTT2_DEVICE mache erstellt er das Gerät, aber dann funktioniert es nicht.
Was kann das sein, habe ich etwas vergessen..?
Zitathabe ich etwas vergessen..?
Ins Log zu gucken...!
Das hatte ich getan und verglichen mit meinem alten Fhem
hier die Logeinträge:
2018.11.12 14:56:00 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_PINGREQ redefined at FHEM/lib/Net/MQTT/Constants.pm line 44.
2018.11.12 14:56:00 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_UNSUBACK redefined at FHEM/lib/Net/MQTT/Constants.pm line 44.
2018.11.12 14:56:00 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_PUBREC redefined at FHEM/lib/Net/MQTT/Constants.pm line 44.
2018.11.12 14:56:00 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_CONNACK redefined at FHEM/lib/Net/MQTT/Constants.pm line 44.
2018.11.12 14:56:00 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_CONNECT_ACCEPTED redefined at FHEM/lib/Net/MQTT/Constants.pm line 44.
2018.11.12 14:56:00 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_PUBLISH redefined at FHEM/lib/Net/MQTT/Constants.pm line 44.
2018.11.12 14:56:00 1: PERL WARNING: Constant subroutine MQTT::DEVICE::MQTT_CONNECT redefined at FHEM/lib/Net/MQTT/Constants.pm line 44
Mir ist so als wenn ich ich auf Perl Ebene etwas nachinstallieren muss..!
Aber ich weiß grad nicht was :-\
Hatte schon im Forum gesucht bisher aber noch nichts brauchbares gefunden bei der Suche nach mqtt
Nimm doch einfach mqtt2_client statt mqtt2 als io-Device.
mein IODev ist der "mqttiobroker" und das gesamte Device läßt sich auch anlegen als MQTT2_DEVICE nur kann ich es nicht schalten
Ich weiß da grad nicht weiter ein MQTT_DEVICE kann ich immer noch nicht anlegen da kommt immer ein Fehler, wenn ich in der Befehlszeile eingebe
define AU_Landroid MQTT_DEVICE kommt folgendes
client device hash no IODev provided
das muss ich aber doch erst danach als attr eingeben.
Ich verstehe grad gar nichts mehr :-\
Das kann ich nicht schalten, aber eben anlegen
mein List vom Gerät
Internals:
DEVICETOPIC AU_Landroid
IODev mqttiobroker
NAME AU_Landroid
NR 1951
STATE ???
TYPE MQTT2_DEVICE
Attributes:
IODev mqttiobroker
alias Ladestation Landy
devStateIcon Ein:scene_robo_lawnmower@crimson Aus:scene_robo_lawnmower@lightgreen
event-on-change-reading state,status
eventMap ON:Ein OFF:Aus
group Rasenmäher - Landy
icon scene_robo_lawnmower@blue
room Draußen,HWR,MQTT
sortby 02
stateFormat state
subscribeReading_state stat/AU_Landroid/POWER
subscribeReading_status tele/AU_Landroid/STATUS
userattr subscribeReading_POWER subscribeReading_state subscribeReading_status
webCmd Ein:Aus
Sorry, wenn ich da evtl. unpräzise war, aber es ging um den TYPE deines IODev, nicht um den Namen.
Das habe ich jetzt mal gemacht, leider habe ich noch nicht verstanden warum. (habe schon in der commanref gelesen) aber verstehe nur Bahnhof :-\
Aber Ein/Aus schalten kann ich das Gerät immer noch nicht.
Hier mal ein list:
Internals:
BUF
DEF 10.0.0.31:1883
DeviceName 10.0.0.31:1883
FD 5
NAME AU_Landroid
NR 1968
PARTIAL
STATE opened
TYPE MQTT2_CLIENT
WBCallback
clientId mqttiobroker
connecting 3
lastMsgTime 1542037791.04809
nextOpenDelay 5
READINGS:
2018-11-12 16:47:21 state opened
Attributes:
alias Ladestation Landy
clientId mqttiobroker
devStateIcon Ein:scene_robo_lawnmower@crimson Aus:scene_robo_lawnmower@lightgreen
eventMap ON:Ein OFF:Aus
group Rasenmäher - Landy
icon scene_robo_lawnmower@blue
room Draußen,MQTT
sortby 02
subscribeReading_state stat/AU_Landroid/POWER
subscribeReading_status tele/AU_Landroid/STATUS
userattr subscribeReading_POWER subscribeReading_state subscribeReading_status
webCmd Ein:Aus
ich hatte das noch im Wiki gefunden:
# Perl MQTT Module nachinstallieren (läuft ein paar Minuten)
sudo cpan install Net::MQTT:Simple
sudo cpan install Net::MQTT:Constants
aber nun kann ich gar kein MQTT_DEVICE mehr anlegen.
Was ist da schief gelaufen, denn auf meinem anderen System funktioniert das ja.
Habe jetzt ich Debian 9 drauf
Du musst dich schon entscheiden, ob es jetzt mqtt2 oder mqtt2 sein soll, über die du die Geräte anlegen willst.
Wenn mqtt, dann: io-TYPE=MQTT, wenn mqtt2, dann (für mosquitto) io-TYPE=MQTT2_CLIENT.
Da du jetzt doch mqtt ohne die neuen Module haben willst, musst du halt die Perl-Installation erweitern.
ich wollte das ja mit MQTT_DEVICE machen genauso wie ich es schon habe, aber das funktionierte eben nicht.
Ich habe ausser dieser CPAN Installation nichts gefunden, aber da ist wohl irgend etwas schief gelaufen.
Im Moment habe ich da grad ein Brett vor dem Kopf. Den moquitto nutze ich nicht ich habe einen Broker bei ioBroker eingerichtet..
Ich habe mir glaube ich meine Fhem Installation kaputt installiert immer wenn ich MQTT_DEVICE startet mein fhem nicht mehr.
Aber hier scheint alles OK zu sein:
root@debian-vm:~# cpan -i Net::MQTT::Message
Loading internal null logger. Install Log::Log4perl for logging messages
CPAN::SQLite not installed, trying to work without
Reading '/root/.cpan/sources/authors/01mailrc.txt.gz'
............................................................................DONE
Reading '/root/.cpan/sources/modules/02packages.details.txt.gz'
Database was generated on Mon, 12 Nov 2018 04:29:03 GMT
.............
New CPAN.pm version (v2.16) available.
[Currently running version is v2.1101]
You might want to try
install CPAN
reload cpan
to both upgrade CPAN.pm and run the new version without leaving
the current session.
...............................................................DONE
Reading '/root/.cpan/sources/modules/03modlist.data.gz'
DONE
Net::MQTT::Message is up to date (1.163170).
Welcher externe Broker ist zweitrangig.
Aber da steht nicht, dass mit cpan alles io ist, sondern, dass du das mal updaten solltest. Vielleicht wäre es eine Idee, das zu tun?
Genau um solche Abhängigkeiten zu vermindern, würde ich nochmal einen Blick auf mqtt2-client u. Co. empfehlen ;) .
Ja OK ich werde mir das mit mqtt2-client u. Co. anschauen, aber heute erst mal nicht weil ich da keine Ahnung davon habe was ich wo einsetzen muss.
Ich hatte damit noch gar nichts zutun, habe meine ganzen Sonoffs bisher auf meinem alten System über den auf Fhem installierten mosquitto ans laufen gebracht.
Dieser ganze MQTT2 Konstrukt sagt mir noch nichts. Da braucht es erst einmal ein Beispiel damit ich sehe was wie miteinander kommuniziert.
Ich danke erst mal für die Unterstützung. :)
Broker (ioBroker o. mosquitto) <=> MQTT2_CLIENT <=> MQTT2_DEVICE(s)
Mehr braucht es nicht, ist nicht wesentlich anders als bisher (Broker <=> MQTT <=> MQTT_DEVICE(s))
es ist ja nicht so, dass es hier im Forum keine Rubrik für "MQTT" gäbe...
OK hatte ich noch nicht gesehen, kein Problem habe ich mal hier her verschoben.
Ein wenig habe ich im Wiki gefunden und werde mich da mal etwas schlau machen
Was ich aber so richtig noch nicht gefunden habe ist ein Beschreibung über MQTT2 was ich wie anlege. Meine Versuche haben mir auch etwas automatisch angelegt aber so richtig weiß ich damit nichts anzufangen.
Für wäre wichtig zu wissen, was lege ich zuerst an und wie kann ich mein Gerät dazu bekommen das es auch schaltet.
Vielleicht verrätst du uns, was jetzt vorhanden ist. Nennt sich "list" und wäre für alle beteiligten Devices hilfreich.
Vielleicht reicht es auch, wenn du die neusten threads in diesem Bereich hier mal intensiver studierst. Dazu die commandref zu den beteiligten Modulen lesen. Und ggf. vorhandene Beispiele im wiki.....
So ist es nicht mal Kaffeesatz, was wir begutachten können!
OK, ich habe natürlich viel gelesen... und bin dadurch etwas schluderig gewesen mit meinen Angaben.
Möchte hier meinen Erfolg etwas kommentieren... (bringt ja nichts wen ich sage es funktioniert) andere stehen irgendwann vor dem selben Problem.. ;)
Da mir auch einige Grundkenntnisse fehlen was MQTT2 betrifft ist es mal ganz gut gewesen sich da selbst durch zu ackern ;)
Ich habe jetzt also als erstes den MQTT2_Server eingerichtet und da auch autocreate auf 1.
Da hat er natürlich sofort mein erstes Device erstellt und somit bin ich damit auch klar gekommen, soll heißen es funktioniert ;)
Ich habe es etwas angepasst an meine Bedürfnisse (devStateIcon, eventMap, setList, webCmd) und nun ist es OK
Ich habe meine vorher genutzte Sonoff S20 dafür genommen.
Hier das list:
Internals:
CFGFN ./FHEM/System.cfg
CID OG_S20
DEF OG_S20
DEVICETOPIC MQTT2_DVES_80F6D5
IODev m2server
LASTInputDev m2server
MSGCNT 51
NAME OG_S20_MQTT2
NR 1375
STATE Aus
TYPE MQTT2_DEVICE
m2server_MSGCNT 51
m2server_TIME 2018-11-14 01:20:04
READINGS:
2018-11-14 01:08:46 LWT online
2018-11-14 01:20:04 POWER OFF
2018-11-14 01:20:04 Time 2018-11-14T01:20:04
2018-11-14 01:20:04 Uptime 0T00:24:34
2018-11-14 01:20:04 Vcc 3.152
2018-11-14 01:20:04 Wifi_AP 1
2018-11-14 01:20:04 Wifi_BSSId 9C:C7:A6:11:3E:A5
2018-11-14 01:20:04 Wifi_Channel 11
2018-11-14 01:20:04 Wifi_RSSI 38
2018-11-14 01:20:04 Wifi_SSId Rammstein3399
2018-11-14 01:17:36 state off
Attributes:
IODev m2server
alias OG TV Zimmer - Urlaub - S20
devStateIcon Ein:message_socket_on2@crimson Aus:message_socket_off2@lightgreen
eventMap on:Ein off:Aus
icon message_socket@#0033cc
readingList OG_S20:tele/OG_S20/LWT:.* LWT
OG_S20:cmnd/OG_S20/POWER:.* POWER
OG_S20:tele/OG_S20/INFO1:.* { json2nameValue($EVENT) }
OG_S20:tele/OG_S20/INFO2:.* { json2nameValue($EVENT) }
OG_S20:tele/OG_S20/INFO3:.* { json2nameValue($EVENT) }
OG_S20:stat/OG_S20/RESULT:.* { json2nameValue($EVENT) }
OG_S20:stat/OG_S20/POWER:.* POWER
OG_S20:tele/OG_S20/STATE:.* { json2nameValue($EVENT) }
room MQTT
setList on cmnd/OG_S20/POWER ON
off cmnd/OG_S20/POWER OFF
webCmd Ein:Aus
Hatte natürlich vergessen im Sonoff noch die MQTT-Einstellungen für den "Host" einzutragen der stand noch auf meinem aktuell genutzten System (geht natürlich dann nicht) :-\
Habe auch die "client" Einstellung angepasst.
Jetzt habe ich ein Gerät erst einmal und kann alle anderen so langsam nachziehen, da ich doch einige Sonoffs habe
Ich hoffe andere haben ebenso Erfolg.
Eine Frage habe ich denoch, die anderen Sonoff Geräte arbeiten ja noch mit meinem "mosquitto" auf meinem Produktivsystem Intel-Nuc mit Fhem, dort kann ich doch ebenso einen MQTT" Server einrichten, oder..?
Wenn du auf dem Produktivsystem mosquitto am laufen hast, kannst du das auch - vorerst oder dauerhaft - so lassen.
Empfehlen würde ich aber, den mosquitto AUCH mit MQTT2_CLIENT an fhem anzubinden. Dann kannst du neue Devices als mqtt2-devices erstellen (autocreate funktioniert dann aber nicht/nicht so komfortabel) und bei Bedarf bestehende Devices auf mqtt2-device umstellen. Ob es dann noch Sinn macht, den mosquitto abzuschalten, musst du wissen bzw. kann später entscheiden werden; der Schritt, dann als IO für die mqtt2-devices statt mqtt2-client mqtt2-server zu nutzen ist recht klein....
Zur Klarstellung: Mqtt (das Modul) und mqtt2-client können gleichzeitig auf den mosquitto zugreifen.
ZitatFür wäre wichtig zu wissen, was lege ich zuerst an und wie kann ich mein Gerät dazu bekommen das es auch schaltet.
Hier eine kurzes HOWTO aus meiner Sicht:
- MQTT2_SERVER anlegen (vmtl. mit Argument global)
- Attribut autocreate setzen
- MQTT-Sensor/Aktor anpassen (IP+Port), damit es mit der FHEM-MQTT2_SERVER Instanz Verbindung aufnimmt. Evtl. ClientId anpassen.
- FHEM legt eine MQTT2_DEVICE Instanz an, deren readingsList Attribut bei jedem Eintreffen einer unbekannten Nachricht erweitert wird. Je nach empfagenen Topic-Message wird entweder ein Reading angelegt, oder (wenn es JSON ist) eine Liste von Readings. Der Name der Instanz wird aus der gemeldeten clientId abgeleitet.
- wenn man Geraete hat, die ueber eine MQTT-Bridge (wie zigbee2mqtt) angebunden sind, dann setzt man in der angelegten MQTT2_DEVICE bridgeRegexp, daraufhin werden fuer die angebundenen Geraete neue MQTT2_DEVICE Instanzen angelegt, wenn eine Nachricht von diesen Geraeten ankommt.
- die Schaltbefehle muss man in der MQTT2_DEVICE Instanz per setList manuell angeben, dafuer muss man die Doku des Geraetes studieren, oder hier im Forum/Wiki suchen.
Vermutlich wird das noch vereinfacht:
- autocreate Attribut setzen entfaellt (da die Voreinstellung geaendert wird)
- in MQTT2_DEVICE wird man per "set device model XXX" Attribute wie setList und webCmd/etc setzen koennen, wenn das Geraet in der (zu erstellenden) template "Datenbank" vorhanden ist.
Wenn man statt MQTT2_SERVER mosquitto einsetzt, dann kann man MQTT2_CLIENT verwenden. In diesem Fall ist das vorgehen identisch zu MQTT2_SERVER, bis auf autocreate: MQTT2_CLIENT legt fuer direkt (nicht per bridge) angebundenen Geraete nur ein einziges MQTT2_DEVICE an, d.h. die Readings _aller_ MQTT-Geraete landet hier, und man muss die "richtigen" Instanzen samt readingsList selbst anlegen, und diese danach aus der readingsList der gemeinsamen MQTT2_DEVICE entfernen. Oder man setzt autocreate nicht, dann entfaellt dieses "Sammelgeraet".
Vielen Dank euch beiden, ich werde es jetzt so langsam angehen meine ganzen anderen Sonoffs in MQTT2 zu Switchen, da ich jetzt weiß wie es geht ;)
ZitatIn diesem Fall ist das vorgehen identisch zu MQTT2_SERVER, bis auf autocreate: MQTT2_CLIENT legt fuer direkt (nicht per bridge) angebundenen Geraete nur ein einziges MQTT2_DEVICE an, d.h. die Readings _aller_ MQTT-Geraete landet hier, und man muss die "richtigen" Instanzen samt readingsList selbst anlegen, und diese danach aus der readingsList der gemeinsamen MQTT2_DEVICE entfernen.
genau diesen Fall hatte ich auch und war darüber etwas verwirrt, dass alle Geräte dort auftauchten, nur eben mein Gerät welches ich aktuell umstellen wollte, aber wie schon oben geschrieben hatte ich die IP schon geändert :-\
Ein paar Fragen bleiben noch für mich...!
- Wenn ich in meinem alten FHEM ein MQTT2_Device anlege und ich trage den Broker von meinem alten FHEM (myBroker) ein, schaltet das Gerät nicht.
- den neuen MQTT2_Server (bei mir "m2server) im neuen Fhem kann ich von der alten Fhem Instanz nicht ansprechen, oder würde das gehen?
- einen weiteren MQTT2_Server kann ich im alten Fhem nicht anlegen da startet Fhem nicht mehr ist das normal?
das habe ich mit stateformat POWER gelöst
- und zu guter letzt eine Frage zum "devStatIcon" mit MQTT2, welches sich ändert wenn ich ein Gerät von der Weboberfläche schalte, aber wenn das Gerät automatisch oder am Gerät schaltet bekommt es die Anzeige in der Weboberfläche nicht mit, dass ging bei meinem MQTT vorher. Aber hier ist ja die Readinglist eine andere, dass habe ich noch nicht hinbekommen.
hier noch das aktuelle list, ich hatte die userattr aus meinem MQTT Gerät genommen aber das geht nicht
Internals:
CFGFN ./FHEM/System.cfg
CID DVES_80F6D5
DEF DVES_80F6D5
DEVICETOPIC OG_S20_MQTT2
IODev m2server
LASTInputDev m2server
MSGCNT 79
NAME OG_S20_MQTT2
NR 1379
STATE Aus
TYPE MQTT2_DEVICE
m2server_MSGCNT 79
m2server_TIME 2018-11-14 16:38:13
READINGS:
2018-11-14 12:18:29 Command Unknown
2018-11-14 11:10:19 FallbackTopic OG_S20
2018-11-14 11:10:19 GroupTopic sonoffs
2018-11-14 11:10:19 Hostname OG_S20-5845
2018-11-14 11:10:19 IPAddress 10.0.0.153
2018-11-14 14:43:14 LWT online
2018-11-14 11:10:19 Module Sonoff S2X
2018-11-14 16:38:13 POWER OFF
2018-11-14 11:10:19 RestartReason Power on
2018-11-14 16:38:13 Time 2018-11-14T16:38:12
2018-11-14 16:38:13 Uptime 0T03:15:37
2018-11-14 16:38:13 Vcc 3.152
2018-11-14 11:10:19 Version 6.3.0
2018-11-14 11:10:19 WebServerMode Admin
2018-11-14 16:38:13 Wifi_AP 1
2018-11-14 16:38:13 Wifi_BSSId 9C:C7:A6:11:3E:A5
2018-11-14 16:38:13 Wifi_Channel 11
2018-11-14 16:38:13 Wifi_RSSI 40
2018-11-14 16:38:13 Wifi_SSId Rammstein3399
2018-11-14 16:35:06 state off
Attributes:
IODev m2server
alias OG TV Zimmer - Urlaub - S20
devStateIcon Ein:message_socket_on2@crimson Aus:message_socket_off2@#009933
eventMap on:Ein off:Aus
icon message_socket@#0033cc
readingList DVES_80F6D5:tele/OG_S20/LWT:.* LWT
DVES_80F6D5:cmnd/OG_S20/POWER:.* POWER
DVES_80F6D5:tele/OG_S20/INFO1:.* { json2nameValue($EVENT) }
DVES_80F6D5:tele/OG_S20/INFO2:.* { json2nameValue($EVENT) }
DVES_80F6D5:tele/OG_S20/INFO3:.* { json2nameValue($EVENT) }
DVES_80F6D5:stat/OG_S20/RESULT:.* { json2nameValue($EVENT) }
DVES_80F6D5:stat/OG_S20/POWER:.* POWER
DVES_80F6D5:tele/OG_S20/STATE:.* { json2nameValue($EVENT) }
DVES_80F6D5:tele/OG_S20/LWT:.* LWT
DVES_80F6D5:tele/OG_S20/UPTIME:.* { json2nameValue($EVENT) }
room MQTT
setList on cmnd/OG_S20/POWER ON
off cmnd/OG_S20/POWER OFF
subscribeReading_state DVES_80F6D5:stat/OG_S20/POWER
subscribeReading_status DVES_80F6D5:tele/OG_S20/STATUS
userattr subscribeReading_state subscribeReading_status
webCmd Ein:Aus
>>- einen weiteren MQTT2_Server kann ich im alten Fhem nicht anlegen da startet Fhem nicht mehr ist das normal?
Hast du einen anderen Port genommen? MQTT läuft auf 1883 und wenn der schon von mosquitto-server belegt ist, dann kann es schon sein, das Fhem nicht startet.
Nimm einfach einen anderen Port. Ich hatte auch schon beide Zeitgleich laufen, also einmal den normalen mosquitto-server und MQTT2_Server mit einem anderen Port.
Zwei MQTT Server machen im allgemeinen gar keinen Sinn.
Zitat von: hexenmeister am 14 November 2018, 17:21:24
Zwei MQTT Server machen im allgemeinen gar keinen Sinn.
Zumindest nicht, wenn sie innerhalb einer einzigen FHEM Installation instanziiert werden.
ZitatEin paar Fragen bleiben noch für mich...!
- Wenn ich in meinem alten FHEM ein MQTT2_Device anlege und ich trage den Broker von meinem alten FHEM (myBroker) ein, schaltet das Gerät nicht
Wie trägst du einen Broker ein? Für ein 2-er Devices braucht man ein 2-er IO. Also mqtt2_Server oder mqtt2_client! Vermutlich steht das aber bereits hier im thread.
Bitte tue uns den Gefallen und schreibe zukünftig präziser, was du gemacht hast. Einfachste Möglichkeit: lists der beteiligten Geräte....
Zitat von: hexenmeister am 14 November 2018, 17:21:24
Zwei MQTT Server machen im allgemeinen gar keinen Sinn.
normaler weise auch nicht, da ich aber gerade meine ganzen Geräte umstelle wollte ich den MQTT2_Server für die MQTT2_DEVIVE nutzen...
Zitat von: betateilchen am 14 November 2018, 17:40:09
Zumindest nicht, wenn sie innerhalb einer einzigen FHEM Installation instanziiert werden.
eben drum, ich kann ja von meinem alten Fhem aus den MQTT2_Server in meinem neuen Fhem nicht nutzen, zumindest habe ich es nicht hinbekommen
Zitat von: Beta-User am 14 November 2018, 17:50:53
Wie trägst du einen Broker ein? Für ein 2-er Devices braucht man ein 2-er IO. Also mqtt2_Server oder mqtt2_client! Vermutlich steht das aber bereits hier im thread.
Bitte tue uns den Gefallen und schreibe zukünftig präziser, was du gemacht hast. Einfachste Möglichkeit: lists der beteiligten Geräte....
ich hatte den alten (also mosquitto, heißt bei mir myBroker) eingetragen, aber das geht eben nicht (hast du mir ja schon beantwortet) ;) und den neuen wie gesagt erreiche ich nicht, geht wohl auch nicht.
Welches list möchtest du, ich habe es doch eben angehangen.
Zitat von: mark79 am 14 November 2018, 17:18:57
Hast du einen anderen Port genommen?
das probiere ich jetzt mal...
Ich würde den mosquitto belassen und mit mqtt2_client darauf zugreifen.
Oder mit dem alten mqtt Modul auf den neuen Server zugreifen (und mosquitto entfernen).
Oder eben den mosquitto in bridge Modus mit dem MQTT2_SERVER verbinden.
Aber zwei Server parallel ohne Verbindung... Dann hast du auch zwei voneinander getrennte mqtt Netze. Ist das so gewollt?
Zitat von: hexenmeister am 14 November 2018, 18:39:11
Ich würde den mosquitto belassen und mit mqtt2_client darauf zugreifen.
Oder mit dem alten mqtt Modul auf den neuen Server zugreifen (und mosquitto entfernen).
Oder eben den mosquitto in bridge Modus mit dem MQTT2_SERVER verbinden.
Aber zwei Server parallel ohne Verbindung... Dann hast du auch zwei voneinander getrennte mqtt Netze. Ist das so gewollt?
das hat ja eben nicht funktioniert, ich habe den myBroker (mosquitto) eingetragen in das MQTT2_DEVICE
Zitat von: hexenmeister am 14 November 2018, 18:39:11
Oder mit dem alten mqtt Modul auf den neuen Server zugreifen (und mosquitto entfernen).
Aber zwei Server parallel ohne Verbindung... Dann hast du auch zwei voneinander getrennte mqtt Netze. Ist das so gewollt?
nein keine 2 Server, das ist nur für den Moment damit die noch nicht umgeänderten Geräte weiterhin funktionieren.
Dann werde ich mal versuchen mit den alten Geräten auf den neuen MQTT2_Server zuzugreifen, dass hatte ich noch nicht probiert, aber wird der denn gefunden von den alten Geräten
Im neuen Fhem habe ich bisher keinen mosquitto drauf weil ich ja den MQTT2_Server habe ;)
Nein, nein, nein. Nicht devices mischen. Das geht nicht. Stattdessen temporär mit der mqtt io auf MQTT2_SERVER zugreifen. Ist keine performante Lösung, aber für die Umstellung reicht es.
Zitat
Im neuen Fhem habe ich bisher keinen mosquitto drauf weil ich ja den MQTT2_Server habe
Und was bewegt dich eine funktionierende Lösung durch eine weniger performante zu ersetzen?
ZitatStattdessen temporär mit der mqtt io auf MQTT2_SERVER zugreifen. Ist keine performante Lösung, aber für die Umstellung reicht es.
ja genau mehr möchte ich ja nicht.
Welche ist denn die weniger performante Lösund.?
Ich dachte die MQTT2 Lösungen sind die neuen besseren.
Zitat von: hexenmeister am 14 November 2018, 17:21:24
Zwei MQTT Server machen im allgemeinen gar keinen Sinn.
Zum umstellen macht das schon Sinn, man will ja nicht alles auf einmal machen und es gibt auch Anwendungen, die man nicht über MQTT2_SERVER schicken möchte.
Mein bestes Bespiel ist SNIPS (alexa in lokal), dort werden die Audio Daten über MQTT übertragen.
Für mich ist in deinen Schilderungen weiter völlig unklar, wie IO-Devices und Mqtt-devices (deine eigentlichen Geräte) zusammenhängen. Du scheint ja zwei Systeme parallel zu betreiben.
Also wo ist nun ein Broker, was ist das (scheinbar nur noch mqtt2-server, nirgends mehr mosquitto).
Dann muss auf diesem mit dem richtigen Modul zugegriffen werden. Also mqtt2-device für den Rechner mit dem mqtt2-server, und _auf allen anderen_Rechnern mqtt2-client zusätzlich dazwischen.
Oder eben mosquitto und nur noch jeweils ein IO (mqtt2-client).
Die Option, den mqtt2-server mit dem (klassischen) mqtt- Modul zu brücken, ist IMO nicht gut. Lieber (zumindest) erst mal mosquitto am laufen halten und darauf (auch) mit mqtt2-client zugreifen. Dann ggf. langsam umstellen...
Ich hoffe, das wird nun klarer.
Ein list vom ...-device sagt übrigens NICHTS über das IO (ausser dem beliebig austauschbaren Namen).
Zitat von: mark79 am 14 November 2018, 19:00:35
Zum umstellen macht das schon Sinn, man will ja nicht alles auf einmal machen und es gibt auch Anwendungen, die man nicht über MQTT2_SERVER schicken möchte.
Mein bestes Bespiel ist SNIPS (alexa in lokal), dort werden die Audio Daten über MQTT übertragen.
Ich verstehe schon, wenn man zwei Server zusammen verbindet (BridgeModus), aber zwei getrennte? Muss schon ein Speziallfall sein.
Und wenn man schon ein Mosquitto laufen hat, wozu dann der zweite Server? Mosquitto ist performant genug, Audiodaten samt dem Rest zu übertragen. MQTT2_SERVER ist dafür eher nicht gedacht (und geeignet).
OK kurze Erklärung
Neuer Fhem Server IP 10.0.0.51
Dell T20 mit OMV und einigen VMs u.a. eben der Fhem Server in einer VM
MQTT2_Server - Name - m2server
2 MQTT2 Geräte - die ich noch nicht brauche aber umgestellt habe
---------------------------------------------------------------------------------
Alter Fhem Server IP 10.0.0.50
Intel-NUC i3
MQTT_Server - Name - myBroker (mosquitto)
Hier sind weitere 6 MQTT Geräte angemeldet die aber arbeiten wie z.B. Beleuchtung Garten usw.
-----------------------------------------------------------------------------------------------------------
Beide Fhem Server laufen noch parallel, weil ich am Neuen noch keine Homematic Geräte drin habe das wird noch etwas Arbeit geben.
Deshalb laufen die beide.
Naja mir wurde ja gestern gesagt warum ich nicht gleich auf MQTT2 umstelle und somit habe ich damit begonnen. ;)
Auf dem Neuen habe ich auch kein mosquitto installiert.
Tja was ist nun richtig/gut jetzt bin ich am zweifeln?
2 Screenshots neuer und alter Fhem Server auf dem alten sind nicht alle Geräte zu sehen, einfach nur als Information
Zitat von: moonsorrox am 14 November 2018, 19:00:07
Welche ist denn die weniger performante Lösund.?
Ich dachte die MQTT2 Lösungen sind die neuen besseren.
MQTT2-Geräte sind neuer, beim besser kommt es darauf an. Sie sind leichter zu konfigurieren (von der MQTT_GENERIC_BRIDGE abgesehen) und sind vermutlich sauberer implementiert. Der einzige noch vorhandene Vorteil von alten MQTT-IO liegt daran, dass dieser automatisch nur die in vorhandenen FHEM-Devices konfigurierte Topics aboniert und MQTT2_SERVER lauscht einfach auf alles. Wenn das verbessseert wird, würde ich einen Verbund aus mosquitto und MQTT2_CLIENT am performantesten schätzen. Zugegeben, in kleinen Installationen wird der Unterschied nicht auffallen.
Einen MQTT2_SERVER würde ich entweder den absoluten Anfängern empfehlen, oder für die Fälle, wo Installation von mosquitto (bzw. einem anderen Broker) nicht in Frage kommt bzw. unverhöltnissmäßig wäre.
ZitatTja was ist nun richtig/gut jetzt bin ich am zweifeln?
Ok, habe jetzt was von 6 Geräten gelesen. Für die paar Nachrichten ist es absolut egal, welche Lösung man nimmt.
Zitat von: hexenmeister am 14 November 2018, 19:32:12
Ich verstehe schon, wenn man zwei Server zusammen verbindet (BridgeModus), aber zwei getrennte? Muss schon ein Speziallfall sein.
Und wenn man schon ein Mosquitto laufen hat, wozu dann der zweite Server? Mosquitto ist performant genug, Audiodaten samt dem Rest zu übertragen. MQTT2_SERVER ist dafür eher nicht gedacht (und geeignet).
Ich meinte das so, wenn man gerade umstellen will, z.B. vom MQTT_DEVICE oder Generic auf MQTT2_SERVER, dann bindet man einen Tag lang z.B. die Xiaomi Sachen an und am anderen Tag die Tasmota, ESPeasy Sachen. In der Zeit muss man zwei MQTT Server laufen lassen.
Ich bin bei dir, ich halte den MQTT2_Client auch für besser, weil der mosquitto-server performant, schlank und stabil ist. Ich finde es nur etwas schade, das der MQTT2_Client die Devices nicht auch wie MQTT2_Server automatisch anlernt. Man muss erst ein bridgeRegexp setzen.
Aber das ist jammern auf hohen Niveau und ich habe vorher immer die ganzen mqtt_generic Devices per Hand angelegt. Nur wenn man mal neu anfängt, dann sollte es komfortabler werden. :)
@moonsorrox am besten postest du mal ein list von einem Device was nicht funktioniert oder nicht eingebunden wird. Mit den Screenshots kann man jedenfalls nix anfangen.
So wie ich das verstanden habe, muss man auch bei Tasmota/ESPeasy so was wie eine Client ID setzen, damit es automatisch erkannt wird und angelernt wird. Aber da sind die anderen hier fitter drin. Ich habe das bisher nur einmal getestet.
Danke, jetzt wird das Bild klarer, wie die aktuelle Situation aussieht.
So einen Umzug auf Raten wäre nix für mich, daher die Irritationen.
In der konkreten Situation - unter der Annahme, dass nicht wesentlich mehr mqtt-Geräte (v.a. von weiteren fhem-installationen oder mit großem Datenaufkommen) dazu kommen - würde ich auch perspektivisch nur noch den mqtt2-server nutzen und dann eben Gerät für Gerät (bzw Funktionsgruppenweise) in die neue Installation übertragen.
Meine Serverwechsel waren bisher immer so geartet, dass ich fhem unmittelbar komplett umgezogenen habe. Dazu muss man ggf. dann manches vorbereiten - so hätte ich z.B. den mqtt2-client (o. evtl. auch -Server) auf dem Altsystem parallel betrieben, alles mit mqtt2-client+device umgestellt und dann erst beim Wechsel der zentralen Hardware das IO umgebogen auf mqtt2-server und dabei die IP+Port und Zugangsdaten vom bisherigen mosquitto genutzt....
Damit könnte man dann die neue cfg dann - jedenfalls für diesen Part - im Prinzip ohne besondere Perl-Voraussetzungen auf jede andere (Linux-)Plattform umziehen.
Man lernt nie aus.
Zitat von: mark79 am 14 November 2018, 22:53:18
So wie ich das verstanden habe, muss man auch bei Tasmota/ESPeasy so was wie eine Client ID setzen, damit es automatisch erkannt wird und angelernt wird.
Nein, Jeder Client in MQTT-Netztwerk muss eine ID besitzen. Und zwar eindeutig, sonst gibt es Probleme.
Leider sieht MQTT-Protokoll es nicht vor, die ClientID des Senders mit in die Nachrichten an die Abonennten einzupacken. Daher klappt Autocreate nur begrenzt. Aus meiner Sicht überhaupt kein Verlust. Ich habe 7 FHEM-Instanzen mit Hunderten von unterschiedlichen Topics. Ein Autocreate würde mir in einer Minute alles mit neuen unsinnigen FHEM-Devices zuzuballern. Ich nutze dieses Teufelszeug nicht ;D
Also zur Rückmeldung es ist nicht so das es nicht funktioniert.
Ich habe jetzt zwei Geräte auf meinem alten System auf MQTT2 geändert wobei er mir eines davon ja schon mit autocreate erstellt hat, bis ich die alle so angepasst habe dauert etwas... Und in FTUI muss ich dadurch auch einiges umändern.
Aber funktionieren tun sie...
ich wollte es mir leichter machen mit dem Umzug und der gleichzeitigen Änderung auf MQTT2 ;)
Ich habe auf meinen alten Fhem einfach einen MQTT2 Server mit einem anderen Port 1885 installiert und damit geht das ;)
Auf dem neuen System später dann gibt es wie gesagt keinen MQTT Server mehr da setze ich dann den MQTT2 Server ein und somit brauche ich dann beim Umzug nichts weiter ändern außer den Port auf den Tasmota/Sonoff Geräten und das sehe ich nicht als Problem.
Oh was macht man denn mit 7 Fhem Instanzen ???
ZitatOh was macht man denn mit 7 Fhem Instanzen ???
Die verschiedenen Geräte, Logik etc. voneinander trennen. Kann man als eine Art Multitaskingerweiterung für fhem betrachten. Sie laufen parallel und liefern auf der gleichen Hardware bessere Reaktionszeiten.
OK... verstehe ich nur zum Teil ;)
Ich hatte mir darüber auch mal Gedanken gemacht, aber dann habe ich Probleme mein FTUI darzustellen. Das funktioniert ja nur auf einem Gerät und dann kann er nur die Geräte auf der Fhem Instanz darstellen.
Sicher arbeitest du mit dem ioBroker und hast dann alle 7 Fhem Instanzen in diesem integriert..?
Mein MQTT2 funktioniert mit den zwei Geräten die ich gestern integriert habe, nur meine FTUI Anzeige will da noch nicht so richtig, muss da mal im FTUI Forum fragen, denn vorher ging das super. Er schaltet zwar wenn ich von Hand dort klicke aber er aktualisiert den Zustand nicht. :-\
Um evtl. etwas mehr Klarheit zu schaffen:
- ich habe MQTT2_SERVER gebaut, damit man moeglichst einfach MQTT Geraete in FHEM einbinden kann. Fuer diese Faelle benoetigt man neben MQTT2_SERVER die (automatisch) angelegten MQTT2_DEVICE Instanzen.
- eine Alternative mit weniger autocreate Moeglichkeiten ist mosquitto + MQTT2_CLIENT + (selbst definierte) MQTT2_DEVICE Instanzen.
- einige Benutzer (hexenmeister?) verwenden MQTT als "FHEM2FHEM Ersatz", bzw. um FHEM als Treiber fuer Node-Red/ioBroker/etc einsetzen zu koennen (das war mir Anfangs nicht klar). Fuer diese Benutzer ist sowas wie ein MQTT_GENERIC_BRIDGE notwendig, die (ueber MQTT) die bereits angelegten ZWave/CUL_HM/FS20/dummy/etc FHEM-Instanzen mit entsprechenden Instanzen auf den anderen FHEM/IoBroker/etc Installationen synchronisiert.
- MQTT_GENERIC_BRIDGE funktioniert z.Zt. nur mit dem "alten" MQTT Modul (entspricht in etwa MQTT2_CLIENT), es wird aber daran gearbeitet sie "MQTT2 faehig" zu machen. Damit wird man ueber MQTT2_SERVER oder (mosquitto + MQTT2_CLIENT) sowohl "richtige" MQTT Geraete bedienen, wie auch andere FHEM-Instanzen miteinander synchronisieren.
Zitat von: rudolfkoenig am 15 November 2018, 12:47:45
- einige Benutzer (hexenmeister?) verwenden MQTT als "FHEM2FHEM Ersatz" ... (das war mir Anfangs nicht klar)
...
wie auch andere FHEM-Instanzen miteinander synchronisieren.
Das ist insbesondere dann interessant, wenn die FHEM Installationen nicht innerhalb eines einzelnen lokalen Netzwerkes laufen, sondern räumlich voneinander getrennt sind.
Einfaches Szenario bei mir zuhause:
- In der Wohnung läuft ein FHEM im lokalen Netzwerk mit DSL Anbindung
- Im Schuppen des Carports läuft ein FHEM auf einem RaspberryPi, der mittels UMTS Datenstick ins Internet geht (zu weit entfernt für das eigene WLAN)
Es ist nicht (zumindest nicht ohne immensen Aufwand) möglich, diese beiden Instanzen per FHEM2FHEM zu verbinden, ohne Netzwerkzugänge von außen freigeben zu müssen. Insbesondere die Provider von Mobilfunk-Datendiensten blockieren zudem i.d.R. den Zugriff von aussen komplett.
Also habe ich beide FHEM Instanzen per MQTT an einen mosquitto angebunden, der bei AmazonWebServices auf einer Lightsail Instanz in
Irland Frankfurt (Main) läuft. Und schon kann ich aus der Wohnung das Licht im Carport (Homematic Aktor) einschalten. Und mein FHEM in der Wohnung empfängt aus dem Carport die Daten der Wettersensoren und den mit diesem Abstand vom Wohnhaus sehr gut funktionierenden Gewitterwarner.
IOBroker, HomeAssistant habe ich mir angesehen, aber nicht so richtig warm damit geworden. Muss aber schon sagen, Vis von IOBroker ist schon nicht schlecht. NodeRed dagegen hat sich bei mir eingebürgert.
Über MQTT binde ich mehrere FHEM-Instanzen als fhem2fhem-Ersatz. Ist einfacher und genügsamer :) Und natürlich diverse Geräte, die 'nativ' MQTT sprechen. Eine besonders hübsche Oberfläche habe ich auch nicht, verwende FHEM mit i18 und einem angepassten css. Die Instanz mit der UI hat jedoch nichts drin, außer notwendigen Minimum (FHEMWEB, telne, systemd-watchdog), mqtt-Anbindung und vielen Dummies, die per mqtt angebunden Sensoren- und Aktoren-Rolle spielen.
Hallo,
ich versuche gerade eine Xiaomi Cam per MQTT2 Server in Fhem einzubinden, dazu habe ich die MQTT-Config an der Cam angepasst.
In FHEM am MQTT2-Server kommt auch im Attribut "Retain" etwas an, aber es wird einfach kein Device per autocreate erzeugt ?!
Bin mit MQTT noch nicht ganz so fit, vielleicht kann mir jemand einen Tipp geben.
Retain:
/rtsp_h264_server":"ON","myhome/dafang/rtsp_mjpeg_server":"OFF","myhome/ipcam/dafang":"{\u0022uptime\u0022:\u0022 07:50:13 up 18 min, 0 users, load average: 2.68, 2.94, 2.15\u0022, \u0022ssid\u0022:\u0022myWlan\u0022, \u0022bitrate\u0022:\u002272.2 Mb/s\u0022, \u0022signal_level\u0022:\u002273%\u0022, \u0022link_quality\u0022:\u002281%\u0022, \u0022noise_level\u0022:\u00220%\u0022 }","myhome/ipcam/dafang/brightness":"40","myhome/ipcam/dafang/ir_cut":"ON","myhome/ipcam/dafang/leds/blue":"ON","myhome/ipcam/dafang/leds/ir":"OFF","myhome/ipcam/dafang/leds/yellow":"OFF","myhome/ipcam/dafang/motion/detection":"ON","myhome/ipcam/dafang/motion/send_mail":"OFF","myhome/ipcam/dafang/motion/tracking":"OFF","myhome/ipcam/dafang/motors/horizontal":"0","myhome/ipcam/dafang/motors/vertical":"0","myhome/ipcam/dafang/night_mode":"OFF","myhome/ipcam/dafang/night_mode/auto":"ON","myhome/ipcam/dafang/rtsp_h264_server":"ON","myhome/ipcam/dafang/rtsp_mjpeg_server":"OFF"}
Danke und Gruß
Kalle
Ist "autocreate" in MQTT2_SERVER gesetzt?
Wo kommt diese "Retain" Zeile her?
Ja, autocreate ist gesetzt.
Die Cam publisht alle 30 Sek und scheinbar empfängt der MQTT2-Server auch etwas, das was im Attribut Retain steht ?!
Hast du auch eine autocreate Instanz/FHEM-Geraet (gibt es bei Auslieferung in fhem.cfg)?
Steht was im Log?
Ja eine weitere autocreate Instanz habe ich auch, für Homematic Devices ...
Im Log finde ich zu MQTT2 diese Einträge:
MQTT2_FHEM_Server: MQTT2_FHEM_Server_192.168.178.99_39278/mosqsub|614-DAFANG left us (keepalive check)
1: PERL WARNING: Use of uninitialized value in hash element at ./FHEM/10_MQTT2_DEVICE.pm line 398.
1: PERL WARNING: Use of uninitialized value in hash element at ./FHEM/10_MQTT2_DEVICE.pm line 400.
Zitat1: PERL WARNING: Use of uninitialized value in hash element at ./FHEM/10_MQTT2_DEVICE.pm line 398.
Sowas kommt, wenn man eine MQTT2_DEVICE Instanz ohne spezifizierte clientId (d.h. manuell angelegt) entfernt. Habs gefixt, wird aber keinen Einfluss auf das Problem haben.
ZitatJa eine weitere autocreate Instanz habe ich auch, für Homematic Devices ...
Was genau bedeutet "für Homematic Devices"? Ist ignoreTypes gesetzt?
Naechster Schritt: erst den MQTT2_SERVER mit "attr global verbose 5" log beobachten, und wenn Nachrichten gemeldet werden, dann mit "attr global verbose 5" schauen, warum kein MQTT2_DEVICE angelegt wird.
Das Log von "attr global verbose 5" wuerde mich interessieren, vmtl. kann man danach schon was sagen.
Homatic-Devices war nur ein Beispiel, IgnoreTypes ist nicht gesetzt ...
Hier der Logauszug mit verbose 5:
Connection accepted from MQTT2_FHEM_Server_192.168.178.99_53594
2018.11.22 10:44:25 5: CONNECT: (0)(6)MQIsdp(3)(194)(0)<(0)(19)mosqpub|5507-DAFANG(0)(4)root(0)(0)
2018.11.22 10:44:25 4: MQTT2_FHEM_Server_192.168.178.99_53594 mosqpub|5507-DAFANG CONNECT V:3 keepAlive:60 usr:root
2018.11.22 10:44:25 5: PUBLISH: (0)(29)myhome/ipcam/dafang/leds/blueOFF
2018.11.22 10:44:25 4: MQTT2_FHEM_Server_192.168.178.99_53594 mosqpub|5507-DAFANG PUBLISH myhome/ipcam/dafang/leds/blue:OFF
2018.11.22 10:44:25 5: MQTT2_FHEM_Server_192.168.178.99_52843 mosqsub|237-DAFANG => myhome/ipcam/dafang/leds/blue:OFF
2018.11.22 10:44:25 5: MQTT2_FHEM_Server: dispatch autocreate:mosqpub_5507_DAFANG:myhome/ipcam/dafang/leds/blue:OFF
2018.11.22 10:44:25 5: DISCONNECT:
2018.11.22 10:44:25 4: MQTT2_FHEM_Server_192.168.178.99_53594 mosqpub|5507-DAFANG DISCONNECT
2018.11.22 10:44:25 4: Connection accepted from MQTT2_FHEM_Server_192.168.178.99_53595
2018.11.22 10:44:25 5: CONNECT: (0)(6)MQIsdp(3)(194)(0)<(0)(19)mosqpub|5511-DAFANG(0)(4)root(0)(0)
2018.11.22 10:44:25 4: MQTT2_FHEM_Server_192.168.178.99_53595 mosqpub|5511-DAFANG CONNECT V:3 keepAlive:60 usr:root
2018.11.22 10:44:25 5: PUBLISH: (0)(31)myhome/ipcam/dafang/leds/yellowOFF
2018.11.22 10:44:25 4: MQTT2_FHEM_Server_192.168.178.99_53595 mosqpub|5511-DAFANG PUBLISH myhome/ipcam/dafang/leds/yellow:OFF
2018.11.22 10:44:25 5: MQTT2_FHEM_Server_192.168.178.99_52843 mosqsub|237-DAFANG => myhome/ipcam/dafang/leds/yellow:OFF
2018.11.22 10:44:25 5: MQTT2_FHEM_Server: dispatch autocreate:mosqpub_5511_DAFANG:myhome/ipcam/dafang/leds/yellow:OFF
2018.11.22 10:44:25 5: DISCONNECT:
2018.11.22 10:44:25 4: MQTT2_FHEM_Server_192.168.178.99_53595 mosqpub|5511-DAFANG DISCONNECT
2018.11.22 10:44:25 4: Connection accepted from MQTT2_FHEM_Server_192.168.178.99_53596
2018.11.22 10:44:25 5: CONNECT: (0)(6)MQIsdp(3)(194)(0)<(0)(19)mosqpub|5515-DAFANG(0)(4)root(0)(0)
2018.11.22 10:44:25 4: MQTT2_FHEM_Server_192.168.178.99_53596 mosqpub|5515-DAFANG CONNECT V:3 keepAlive:60 usr:root
2018.11.22 10:44:25 5: PUBLISH: (0)(27)myhome/ipcam/dafang/leds/irOFF
2018.11.22 10:44:25 4: MQTT2_FHEM_Server_192.168.178.99_53596 mosqpub|5515-DAFANG PUBLISH myhome/ipcam/dafang/leds/ir:OFF
2018.11.22 10:44:25 5: MQTT2_FHEM_Server_192.168.178.99_52843 mosqsub|237-DAFANG => myhome/ipcam/dafang/leds/ir:OFF
2018.11.22 10:44:25 5: MQTT2_FHEM_Server: dispatch autocreate:mosqpub_5515_DAFANG:myhome/ipcam/dafang/leds/ir:OFF
2018.11.22 10:44:25 5: DISCONNECT:
2018.11.22 10:44:25 4: MQTT2_FHEM_Server_192.168.178.99_53596 mosqpub|5515-DAFANG DISCONNECT
2018.11.22 10:44:25 4: Connection accepted from MQTT2_FHEM_Server_192.168.178.99_53597
2018.11.22 10:44:25 5: CONNECT: (0)(6)MQIsdp(3)(194)(0)<(0)(19)mosqpub|5518-DAFANG(0)(4)root(0)(0)
2018.11.22 10:44:25 4: MQTT2_FHEM_Server_192.168.178.99_53597 mosqpub|5518-DAFANG CONNECT V:3 keepAlive:60 usr:root
2018.11.22 10:44:25 5: PUBLISH: (0)(26)myhome/ipcam/dafang/ir_cutON
2018.11.22 10:44:25 4: MQTT2_FHEM_Server_192.168.178.99_53597 mosqpub|5518-DAFANG PUBLISH myhome/ipcam/dafang/ir_cut:ON
2018.11.22 10:44:25 5: MQTT2_FHEM_Server_192.168.178.99_52843 mosqsub|237-DAFANG => myhome/ipcam/dafang/ir_cut:ON
2018.11.22 10:44:25 5: MQTT2_FHEM_Server: dispatch autocreate:mosqpub_5518_DAFANG:myhome/ipcam/dafang/ir_cut:ON
2018.11.22 10:44:25 5: DISCONNECT:
2018.11.22 10:44:25 4: MQTT2_FHEM_Server_192.168.178.99_53597 mosqpub|5518-DAFANG DISCONNECT
2018.11.22 10:44:26 4: Connection accepted from MQTT2_FHEM_Server_192.168.178.99_53598
2018.11.22 10:44:26 5: CONNECT: (0)(6)MQIsdp(3)(194)(0)<(0)(19)mosqpub|5524-DAFANG(0)(4)root(0)(0)
2018.11.22 10:44:26 4: MQTT2_FHEM_Server_192.168.178.99_53598 mosqpub|5524-DAFANG CONNECT V:3 keepAlive:60 usr:root
2018.11.22 10:44:26 5: PUBLISH: (0)(30)myhome/ipcam/dafang/brightness40
2018.11.22 10:44:26 4: MQTT2_FHEM_Server_192.168.178.99_53598 mosqpub|5524-DAFANG PUBLISH myhome/ipcam/dafang/brightness:40
2018.11.22 10:44:26 5: MQTT2_FHEM_Server_192.168.178.99_52843 mosqsub|237-DAFANG => myhome/ipcam/dafang/brightness:40
2018.11.22 10:44:26 5: MQTT2_FHEM_Server: dispatch autocreate:mosqpub_5524_DAFANG:myhome/ipcam/dafang/brightness:40
2018.11.22 10:44:26 5: DISCONNECT:
2018.11.22 10:44:26 4: MQTT2_FHEM_Server_192.168.178.99_53598 mosqpub|5524-DAFANG DISCONNECT
2018.11.22 10:44:26 4: Connection accepted from MQTT2_FHEM_Server_192.168.178.99_53599
2018.11.22 10:44:26 5: CONNECT: (0)(6)MQIsdp(3)(194)(0)<(0)(19)mosqpub|5529-DAFANG(0)(4)root(0)(0)
2018.11.22 10:44:26 4: MQTT2_FHEM_Server_192.168.178.99_53599 mosqpub|5529-DAFANG CONNECT V:3 keepAlive:60 usr:root
2018.11.22 10:44:26 5: PUBLISH: (0)$myhome/ipcam/dafang/rtsp_h264_serverON
2018.11.22 10:44:26 4: MQTT2_FHEM_Server_192.168.178.99_53599 mosqpub|5529-DAFANG PUBLISH myhome/ipcam/dafang/rtsp_h264_server:ON
2018.11.22 10:44:26 5: MQTT2_FHEM_Server_192.168.178.99_52843 mosqsub|237-DAFANG => myhome/ipcam/dafang/rtsp_h264_server:ON
2018.11.22 10:44:26 5: MQTT2_FHEM_Server: dispatch autocreate:mosqpub_5529_DAFANG:myhome/ipcam/dafang/rtsp_h264_server:ON
2018.11.22 10:44:26 5: DISCONNECT:
2018.11.22 10:44:26 4: MQTT2_FHEM_Server_192.168.178.99_53599 mosqpub|5529-DAFANG DISCONNECT
2018.11.22 10:44:26 4: Connection accepted from MQTT2_FHEM_Server_192.168.178.99_53600
2018.11.22 10:44:26 5: CONNECT: (0)(6)MQIsdp(3)(194)(0)<(0)(19)mosqpub|5534-DAFANG(0)(4)root(0)(0)
2018.11.22 10:44:26 4: MQTT2_FHEM_Server_192.168.178.99_53600 mosqpub|5534-DAFANG CONNECT V:3 keepAlive:60 usr:root
2018.11.22 10:44:26 5: PUBLISH: (0)%myhome/ipcam/dafang/rtsp_mjpeg_serverOFF
2018.11.22 10:44:26 4: MQTT2_FHEM_Server_192.168.178.99_53600 mosqpub|5534-DAFANG PUBLISH myhome/ipcam/dafang/rtsp_mjpeg_server:OFF
2018.11.22 10:44:26 5: MQTT2_FHEM_Server_192.168.178.99_52843 mosqsub|237-DAFANG => myhome/ipcam/dafang/rtsp_mjpeg_server:OFF
2018.11.22 10:44:26 5: MQTT2_FHEM_Server: dispatch autocreate:mosqpub_5534_DAFANG:myhome/ipcam/dafang/rtsp_mjpeg_server:OFF
2018.11.22 10:44:26 5: DISCONNECT:
2018.11.22 10:44:26 4: MQTT2_FHEM_Server_192.168.178.99_53600 mosqpub|5534-DAFANG DISCONNECT
2018.11.22 10:44:26 4: Connection accepted from MQTT2_FHEM_Server_192.168.178.99_53601
2018.11.22 10:44:26 5: CONNECT: (0)(6)MQIsdp(3)(194)(0)<(0)(19)mosqpub|5537-DAFANG(0)(4)root(0)(0)
2018.11.22 10:44:26 4: MQTT2_FHEM_Server_192.168.178.99_53601 mosqpub|5537-DAFANG CONNECT V:3 keepAlive:60 usr:root
2018.11.22 10:44:26 5: PUBLISH: (0)(30)myhome/ipcam/dafang/night_modeOFF
2018.11.22 10:44:26 4: MQTT2_FHEM_Server_192.168.178.99_53601 mosqpub|5537-DAFANG PUBLISH myhome/ipcam/dafang/night_mode:OFF
2018.11.22 10:44:26 5: MQTT2_FHEM_Server_192.168.178.99_52843 mosqsub|237-DAFANG => myhome/ipcam/dafang/night_mode:OFF
2018.11.22 10:44:26 5: MQTT2_FHEM_Server: dispatch autocreate:mosqpub_5537_DAFANG:myhome/ipcam/dafang/night_mode:OFF
2018.11.22 10:44:26 5: DISCONNECT:
2018.11.22 10:44:26 4: MQTT2_FHEM_Server_192.168.178.99_53601 mosqpub|5537-DAFANG DISCONNECT
2018.11.22 10:44:26 4: Connection accepted from MQTT2_FHEM_Server_192.168.178.99_53602
2018.11.22 10:44:26 5: CONNECT: (0)(6)MQIsdp(3)(194)(0)<(0)(19)mosqpub|5539-DAFANG(0)(4)root(0)(0)
2018.11.22 10:44:26 4: MQTT2_FHEM_Server_192.168.178.99_53602 mosqpub|5539-DAFANG CONNECT V:3 keepAlive:60 usr:root
2018.11.22 10:44:26 5: PUBLISH: (0)#myhome/ipcam/dafang/night_mode/autoON
2018.11.22 10:44:26 4: MQTT2_FHEM_Server_192.168.178.99_53602 mosqpub|5539-DAFANG PUBLISH myhome/ipcam/dafang/night_mode/auto:ON
2018.11.22 10:44:26 5: MQTT2_FHEM_Server_192.168.178.99_52843 mosqsub|237-DAFANG => myhome/ipcam/dafang/night_mode/auto:ON
2018.11.22 10:44:26 5: MQTT2_FHEM_Server: dispatch autocreate:mosqpub_5539_DAFANG:myhome/ipcam/dafang/night_mode/auto:ON
2018.11.22 10:44:26 5: DISCONNECT:
2018.11.22 10:44:26 4: MQTT2_FHEM_Server_192.168.178.99_53602 mosqpub|5539-DAFANG DISCONNECT
2018.11.22 10:44:27 4: Connection accepted from MQTT2_FHEM_Server_192.168.178.99_53603
2018.11.22 10:44:27 5: CONNECT: (0)(6)MQIsdp(3)(194)(0)<(0)(19)mosqpub|5542-DAFANG(0)(4)root(0)(0)
2018.11.22 10:44:27 4: MQTT2_FHEM_Server_192.168.178.99_53603 mosqpub|5542-DAFANG CONNECT V:3 keepAlive:60 usr:root
2018.11.22 10:44:27 5: PUBLISH: (0)$myhome/ipcam/dafang/motion/detectionON
2018.11.22 10:44:27 4: MQTT2_FHEM_Server_192.168.178.99_53603 mosqpub|5542-DAFANG PUBLISH myhome/ipcam/dafang/motion/detection:ON
2018.11.22 10:44:27 5: MQTT2_FHEM_Server_192.168.178.99_52843 mosqsub|237-DAFANG => myhome/ipcam/dafang/motion/detection:ON
2018.11.22 10:44:27 5: MQTT2_FHEM_Server: dispatch autocreate:mosqpub_5542_DAFANG:myhome/ipcam/dafang/motion/detection:ON
2018.11.22 10:44:27 5: DISCONNECT:
2018.11.22 10:44:27 4: MQTT2_FHEM_Server_192.168.178.99_53603 mosqpub|5542-DAFANG DISCONNECT
2018.11.22 10:44:27 4: Connection accepted from MQTT2_FHEM_Server_192.168.178.99_53604
2018.11.22 10:44:27 5: CONNECT: (0)(6)MQIsdp(3)(194)(0)<(0)(19)mosqpub|5547-DAFANG(0)(4)root(0)(0)
2018.11.22 10:44:27 4: MQTT2_FHEM_Server_192.168.178.99_53604 mosqpub|5547-DAFANG CONNECT V:3 keepAlive:60 usr:root
2018.11.22 10:44:27 5: PUBLISH: (0)$myhome/ipcam/dafang/motion/send_mailOFF
2018.11.22 10:44:27 4: MQTT2_FHEM_Server_192.168.178.99_53604 mosqpub|5547-DAFANG PUBLISH myhome/ipcam/dafang/motion/send_mail:OFF
2018.11.22 10:44:27 5: MQTT2_FHEM_Server_192.168.178.99_52843 mosqsub|237-DAFANG => myhome/ipcam/dafang/motion/send_mail:OFF
2018.11.22 10:44:27 5: MQTT2_FHEM_Server: dispatch autocreate:mosqpub_5547_DAFANG:myhome/ipcam/dafang/motion/send_mail:OFF
2018.11.22 10:44:27 5: DISCONNECT:
2018.11.22 10:44:27 4: MQTT2_FHEM_Server_192.168.178.99_53604 mosqpub|5547-DAFANG DISCONNECT
2018.11.22 10:44:27 4: Connection accepted from MQTT2_FHEM_Server_192.168.178.99_53605
2018.11.22 10:44:27 5: CONNECT: (0)(6)MQIsdp(3)(194)(0)<(0)(19)mosqpub|5550-DAFANG(0)(4)root(0)(0)
2018.11.22 10:44:27 4: MQTT2_FHEM_Server_192.168.178.99_53605 mosqpub|5550-DAFANG CONNECT V:3 keepAlive:60 usr:root
2018.11.22 10:44:27 5: PUBLISH: (0)#myhome/ipcam/dafang/motion/trackingOFF
2018.11.22 10:44:27 4: MQTT2_FHEM_Server_192.168.178.99_53605 mosqpub|5550-DAFANG PUBLISH myhome/ipcam/dafang/motion/tracking:OFF
2018.11.22 10:44:27 5: MQTT2_FHEM_Server_192.168.178.99_52843 mosqsub|237-DAFANG => myhome/ipcam/dafang/motion/tracking:OFF
2018.11.22 10:44:27 5: MQTT2_FHEM_Server: dispatch autocreate:mosqpub_5550_DAFANG:myhome/ipcam/dafang/motion/tracking:OFF
2018.11.22 10:44:27 5: DISCONNECT:
2018.11.22 10:44:27 4: MQTT2_FHEM_Server_192.168.178.99_53605 mosqpub|5550-DAFANG DISCONNECT
2018.11.22 10:44:27 4: Connection accepted from MQTT2_FHEM_Server_192.168.178.99_53606
2018.11.22 10:44:27 5: CONNECT: (0)(6)MQIsdp(3)(194)(0)<(0)(19)mosqpub|5557-DAFANG(0)(4)root(0)(0)
2018.11.22 10:44:27 4: MQTT2_FHEM_Server_192.168.178.99_53606 mosqpub|5557-DAFANG CONNECT V:3 keepAlive:60 usr:root
2018.11.22 10:44:27 5: PUBLISH: (0)#myhome/ipcam/dafang/motors/vertical0
2018.11.22 10:44:27 4: MQTT2_FHEM_Server_192.168.178.99_53606 mosqpub|5557-DAFANG PUBLISH myhome/ipcam/dafang/motors/vertical:0
2018.11.22 10:44:27 5: MQTT2_FHEM_Server_192.168.178.99_52843 mosqsub|237-DAFANG => myhome/ipcam/dafang/motors/vertical:0
2018.11.22 10:44:27 5: MQTT2_FHEM_Server: dispatch autocreate:mosqpub_5557_DAFANG:myhome/ipcam/dafang/motors/vertical:0
2018.11.22 10:44:27 5: DISCONNECT:
2018.11.22 10:44:27 4: MQTT2_FHEM_Server_192.168.178.99_53606 mosqpub|5557-DAFANG DISCONNECT
2018.11.22 10:44:27 4: Connection accepted from MQTT2_FHEM_Server_192.168.178.99_53607
2018.11.22 10:44:27 5: CONNECT: (0)(6)MQIsdp(3)(194)(0)<(0)(19)mosqpub|5564-DAFANG(0)(4)root(0)(0)
2018.11.22 10:44:27 4: MQTT2_FHEM_Server_192.168.178.99_53607 mosqpub|5564-DAFANG CONNECT V:3 keepAlive:60 usr:root
2018.11.22 10:44:27 5: PUBLISH: (0)%myhome/ipcam/dafang/motors/horizontal100
2018.11.22 10:44:27 4: MQTT2_FHEM_Server_192.168.178.99_53607 mosqpub|5564-DAFANG PUBLISH myhome/ipcam/dafang/motors/horizontal:100
2018.11.22 10:44:27 5: MQTT2_FHEM_Server_192.168.178.99_52843 mosqsub|237-DAFANG => myhome/ipcam/dafang/motors/horizontal:100
2018.11.22 10:44:27 5: MQTT2_FHEM_Server: dispatch autocreate:mosqpub_5564_DAFANG:myhome/ipcam/dafang/motors/horizontal:100
2018.11.22 10:44:27 5: DISCONNECT:
2018.11.22 10:44:27 4: MQTT2_FHEM_Server_192.168.178.99_53607 mosqpub|5564-DAFANG DISCONNECT
2018.11.22 10:44:28 4: Connection accepted from MQTT2_FHEM_Server_192.168.178.99_53608
2018.11.22 10:44:28 5: CONNECT: (0)(6)MQIsdp(3)(194)(0)<(0)(19)mosqpub|5596-DAFANG(0)(4)root(0)(0)
2018.11.22 10:44:28 4: MQTT2_FHEM_Server_192.168.178.99_53608 mosqpub|5596-DAFANG CONNECT V:3 keepAlive:60 usr:root
2018.11.22 10:44:28 5: PUBLISH: (0)(19)myhome/ipcam/dafang{"uptime":" 10:44:27 up 27 min, 0 users, load average: 2.59, 2.73, 2.32", "ssid":"Fehler aufgetreten !", "bitrate":"72.2 Mb/s", "signal_level":"76%", "link_quality":"89%", "noise_level":"0%" }
2018.11.22 10:44:28 4: MQTT2_FHEM_Server_192.168.178.99_53608 mosqpub|5596-DAFANG PUBLISH myhome/ipcam/dafang:{"uptime":" 10:44:27 up 27 min, 0 users, load average: 2.59, 2.73, 2.32", "ssid":"Fehler aufgetreten !", "bitrate":"72.2 Mb/s", "signal_level":"76%", "link_quality":"89%", "noise_level":"0%" }
2018.11.22 10:44:28 5: MQTT2_FHEM_Server_192.168.178.99_52843 mosqsub|237-DAFANG => myhome/ipcam/dafang:{"uptime":" 10:44:27 up 27 min, 0 users, load average: 2.59, 2.73, 2.32", "ssid":"Fehler aufgetreten !", "bitrate":"72.2 Mb/s", "signal_level":"76%", "link_quality":"89%", "noise_level":"0%" }
2018.11.22 10:44:28 5: MQTT2_FHEM_Server: dispatch autocreate:mosqpub_5596_DAFANG:myhome/ipcam/dafang:{"uptime":" 10:44:27 up 27 min, 0 users, load average: 2.59, 2.73, 2.32", "ssid":"Fehler aufgetreten !", "bitrate":"72.2 Mb/s", "signal_level":"76%", "link_quality":"89%", "noise_level":"0%" }
2018.11.22 10:44:28 5: DISCONNECT:
2018.11.22 10:44:28 4: MQTT2_FHEM_Server_192.168.178.99_53608 mosqpub|5596-DAFANG DISCONNECT
2018.11.22 10:44:50 5: PINGREQ:
2018.11.22 10:44:50 4: MQTT2_FHEM_Server_192.168.178.99_52843 mosqsub|237-DAFANG PINGREQ
Die MQTT Implementation der Xiaomi Cam ruft fuer jede Nachricht das mosquitto_pub Programm auf.
Die voreingestellte clientid von mosquitto_pub ist mosqpub|<pid> (wobei pid bei jedem Aufruf sich aendert). Um nicht fuer jeden Programmaufruf eine neue MQTT2_DEVICE Instanz anzulegen, ignoriert das Modul fuer autocreate alles, was mit mosqpub anfaengt. Bei manuellen Aufruf von mosquitto_pub kann man mit -i ein clientId setzen, das muesste man fuer Xiaomi Cam auch irgendwie machen, damit autocreate funktioniert. Sonst bleibt nur das manuelle Anlegen der MQTT2_DEVICE samt readingList.
Ah OK, das erklärt es.
Ich habe in der MQTT-Config der Cam die Option -i <client-id> gefunden und gesetzt, nun hat Autocreate ein Device angelegt ;)
Vielen Dank für die Mühe !!!
Gruß Kalle
Hallo,
ich habe auch ein (hoffentlich) kleines Problem mit MQTT2.
Ich betreibe aktuell 2 Sonoff Basic (werden aber noch viele mehr), z.T. auch mit Zusatzsensoren (1x switch, 1x DHT11). Anlegen per "autocreate" hat super funktioniert. Auch kann ich die Geräte von FHEM aus schalten und es werden auch die Zusatzsensoren angezeigt.
Das Problem das ich im Moment noch habe ist, daß ich zwar von FHEM aus schalten kann, ich aber keine Rückmeldung in FHEM bekomme wenn ich am Device selbst, oder per Tasmota Web-IF schalte.
In den Readings wird in diesem Fall zwar "POWER" umgesetzt (von ON zu OFF und umgekehrt), aber "state" nicht. Bei Bedienung in FHEM wird beides umgeschaltet. Woran könnte das liegen?
Hier meine Konfi:
Dieses Problem hatte ich auch, dass habe ich dann so gelöst..
List vom Gerät:
Internals:
CFGFN ./FHEM/System.cfg
CID DVES_80F6D5
DEF DVES_80F6D5
DEVICETOPIC OG_S20_MQTT2
IODev m2server
LASTInputDev m2server
MSGCNT 177
NAME OG_S20_MQTT2
NR 1385
STATE OFF
TYPE MQTT2_DEVICE
m2server_MSGCNT 177
m2server_TIME 2018-12-11 23:25:09
READINGS:
2018-11-14 12:18:29 Command Unknown
2018-12-10 15:34:08 FallbackTopic DVES_80F6D5
2018-12-10 15:34:08 GroupTopic sonoffs
2018-12-10 15:34:08 Hostname OG_S20-5845
2018-12-10 15:34:08 IPAddress 10.0.0.153
2018-12-11 10:01:30 LWT online
2018-12-10 15:34:08 Module Sonoff S2X
2018-12-11 23:25:09 POWER OFF
2018-12-10 15:34:08 RestartReason Software/System restart
2018-12-11 23:25:09 Time 2018-12-11T23:25:08
2018-12-11 23:25:09 Uptime 1T07:51:25
2018-12-11 23:25:09 Vcc 3.152
2018-12-10 15:34:08 Version 6.3.0
2018-12-10 15:34:08 WebServerMode Admin
2018-12-11 23:25:09 Wifi_AP 1
2018-12-11 23:25:09 Wifi_BSSId xx:xx:xx:xx:3E:A5
2018-12-11 23:25:09 Wifi_Channel 11
2018-12-11 23:25:09 Wifi_RSSI 34
2018-12-11 23:25:09 Wifi_SSId XXXXXXXXXXXXXXXXXX
2018-12-11 00:31:46 state off
Attributes:
IODev m2server
alias OG TV Zimmer - S20
devStateIcon ON:message_socket_on2@crimson OFF:message_socket_off2@lightgreen
eventMap on:Ein off:Aus
icon message_socket@blue
readingList DVES_80F6D5:tele/OG_S20/LWT:.* LWT
DVES_80F6D5:cmnd/OG_S20/POWER:.* POWER
DVES_80F6D5:tele/OG_S20/INFO1:.* { json2nameValue($EVENT) }
DVES_80F6D5:tele/OG_S20/INFO2:.* { json2nameValue($EVENT) }
DVES_80F6D5:tele/OG_S20/INFO3:.* { json2nameValue($EVENT) }
DVES_80F6D5:stat/OG_S20/RESULT:.* { json2nameValue($EVENT) }
DVES_80F6D5:stat/OG_S20/POWER:.* POWER
DVES_80F6D5:tele/OG_S20/STATE:.* { json2nameValue($EVENT) }
DVES_80F6D5:tele/OG_S20/UPTIME:.* { json2nameValue($EVENT) }
room MQTT,OG - Flur
setList on cmnd/OG_S20/POWER ON
off cmnd/OG_S20/POWER OFF
stateFormat POWER
und hier nochmal die RAW definition:
defmod OG_S20_MQTT2 MQTT2_DEVICE DVES_80F6D5
attr OG_S20_MQTT2 IODev m2server
attr OG_S20_MQTT2 alias OG TV Zimmer - S20
attr OG_S20_MQTT2 devStateIcon ON:message_socket_on2@crimson OFF:message_socket_off2@lightgreen
attr OG_S20_MQTT2 eventMap on:Ein off:Aus
attr OG_S20_MQTT2 icon message_socket@blue
attr OG_S20_MQTT2 readingList DVES_80F6D5:tele/OG_S20/LWT:.* LWT\
DVES_80F6D5:cmnd/OG_S20/POWER:.* POWER\
DVES_80F6D5:tele/OG_S20/INFO1:.* { json2nameValue($EVENT) }\
DVES_80F6D5:tele/OG_S20/INFO2:.* { json2nameValue($EVENT) }\
DVES_80F6D5:tele/OG_S20/INFO3:.* { json2nameValue($EVENT) }\
DVES_80F6D5:stat/OG_S20/RESULT:.* { json2nameValue($EVENT) }\
DVES_80F6D5:stat/OG_S20/POWER:.* POWER\
DVES_80F6D5:tele/OG_S20/STATE:.* { json2nameValue($EVENT) }\
DVES_80F6D5:tele/OG_S20/UPTIME:.* { json2nameValue($EVENT) }
attr OG_S20_MQTT2 room MQTT,OG - Flur
attr OG_S20_MQTT2 setList on cmnd/OG_S20/POWER ON\
off cmnd/OG_S20/POWER OFF
attr OG_S20_MQTT2 stateFormat POWER
Für die Sonoff gibt es zwischenzeitlich auch ein paar templates, die man einfach mit "set <device> attrTemplate ..." anwenden kann.
Wenn es damit Probleme gibt oder Verbesserungsvorschläge: sollte Eingang in die templates finden, das macht es m.E. für alle viel einfacher, die erstmals damit in Kontakt kommen.
@ moonsorrox
Das attr "stateFormat" war der richtige Tip. Damit ist jetzt die Anzeige synchron zur Schaltstellung, egal von wo (manuell am Sonoff Basic, über das Tasmota Web-IF, oder aus FHEM) geschaltet wird. Das der "state" im MQTT2-Device nicht synchron zum (von mir verwendeten) reading "POWER" ist kann ich damit verschmerzen.
@Beta-User
Was meinst Du für Templates für sonoff-devices? Wo findet man die?
Zitat von: Guzzi-Charlie am 13 Dezember 2018, 14:16:20
@Beta-User
Was meinst Du für Templates für sonoff-devices? Wo findet man die?
Wenn dein FHEM aktuell ist, sollte bei jedem MQTT2_SEVICE ein "set" mit "attrTemplate" vorhanden sein - die Liste mit den verfügbaren templates als Auswahlfeld dahinter. Kann man eigentlich kaum verfehlen ;) ...
Wenn Verbesserungsbedarf besteht: bitte melden, habe mich "erfolgreich" als Maintainer für den Teil "beworben". Voraussichtlich mache ich am WE einen neuen Thread dazu auf, wenn svn tut, was ich will, bin da noob ::) . Dann können da zentral diese Dinge besprochen werden.
Zu dem Thema Anzeige des Schaltvorgangs habe ich hier (https://forum.fhem.de/index.php/topic,91394.msg871189.html#msg871189) einen Vorschlag gepostet, den aber Rudi mit einem für mich verwirrenden Hinweis auf Tasmota hinterfragt hat. Da ich keine Tasmota-(oder shelly-) Switches (und schon gleich keine mehrfachen) habe, kann ich das schlecht verifizieren. Vielleicht macht sich jemand die Mühe, das Mehrfach-Shelly-template für tasmota zu adaptieren und dabei sicherzustellen, dass das set-Reading mit dem Ergebnis-Reading vom Namen her zusammenpaßt (ich vermute da die eigentliche Ursache für die Sorge von Rudi).
Was mir bei den Tasmota-templates und der darin enthaltenen "getList" allerdings bisher unklar ist: da steht das reading, das das Ergebnis beinhalten soll im Moment in der template-File hinten, lt. commandref sollte es in der Mitte stehen. Was ist denn jetzt richtig? (ich habe das erst gestern so richtig wahrgenommen, dass es sowas gibt und daher noch nichts passendes testen können).
ZitatWas mir bei den Tasmota-templates und der darin enthaltenen "getList" allerdings bisher unklar ist: da steht das reading, das das Ergebnis beinhalten soll im Moment in der template-File hinten, lt. commandref sollte es in der Mitte stehen.
Das war ein copy&paste Fehler in der Doku.
getList ist egal, in welchem Reading es landet, das bestimmt weiterhin readingList.
Hallo
Ich habe ein Problem mit MQTT2 und weewx.
Eigentlich überträgt weewx die Wetterdaten brav an Fhem per MQTT.
Nun habe ich MQTT2 ausprobiert und musste feststellen das immer wenn Weewx Daten sendet auch ein neues Device angelegt wird.
Im laufe des letzten Tages sind da schon eine dazu gekommen.
Wie kann ich verhinder das immer neue Device angelgt werden ?
z.B. MQTT2_weewx_0ccbaedd
MQTT2_weewx_0d56f84e
Grüße André
https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele (https://wiki.fhem.de/wiki/MQTT2-Module_-_Praxisbeispiele), dort:
Ständig neue Devices ?