zigbee2tasmota_bridge - keine Devices werden angelegt

Begonnen von traders-banquet, 06 August 2021, 09:24:45

Vorheriges Thema - Nächstes Thema

Beta-User

#15
Hattest du ein reguläres update gemacht oder die Datei aus dem svn geholt?

Per update kommt die aktualisierte Fassung erst ab heute 8:00 Uhr, wenn es gestern nach 8:00 Uhr im svn gelandet war ;) .

Und auch ohne das (weiter m.E. nicht zu empfehlende rename) hätte es direkt mit den kurzen Readings klappen sollten, wenn du einfach DEV_ID (die 4 Buchstaben) hinter die 0x gemacht hättest (statt des einen Punkts).
Wäre klasse, wenn du die upgedatete Variante testen könntest...

[OT]rereadcfg hat sicher nicht geholfen, den Befehl an sich solltest du aus deinem repertoire streichen (das kann sehr komische Nebenwirkungen haben) und das Editieren der cfg an sich ist für Einsteiger nicht zu empfehlen. Besser das "grüne Plus" bzw. den RAW-Import nutzen (ganz unten auf den Detailansichten).[/OT]
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

traders-banquet

Ich mache gerade ein update all und werde es dann nochmal probieren.
Mit dem rereadcfg habe ich die Anwendung des Templates rückgängig gemacht, da die Config bei mir nicht automatisch gespeichert wird, daher hat der Befehl genau das getan was er sollte.
Die meisten meiner Devices habe ich selber eingetragen aber hier hat sicherlich jeder seinen eigenen Präferenzen, gefühlt geht es schneller, wenn man einen eintragen lässt, diesen dann durchkonfiguriert und wenn der Aktor dann so funktioniert, wie man es gerne hätte, dann werden die nächsten 6 in die Config eingetragen und entsprechend umbenannt, das geht viel schneller als alle dann jeweils anzupassen.

Das Template ist nun auch vom Datum aktuell, gestern war mir direkt aufgefallen, dass das Template Datum noch veraltet war und es wunderte mich nur, das alle Zigbee Templates dennoch sichtbar wurden.
Ich erhalte bei der Anwendung des Templates folgende Fehlermeldung :

ERROR executing perl-code { my $rL = AttrVal("MQTT2_z2t_7D99",'readingList',''); $rL =~ m,([^:]*)\b(tele|cmnd|stat)(/.*/[^/]+/SENSOR)?:, ? "${1}tele$3" : $rL =~ m,([^:]*)\b(/.*/[^/].{4})/tele/SENSOR ? qq{${1}/tele/SENSOR} : undef } for param TELETOPIC: Search pattern not terminated at (eval 13517) line 1.



Otto123

Zitat von: traders-banquet am 09 August 2021, 08:03:58
Ein Topic soll nicht mit einem / beginnen ? Ist das irgendwo beschrieben oder handelt es sich dabei nur um persönliche Präferenzen. Ich habe alle meine full Topics mit einem / begonnen. Grundsätzlich habe ich dadurch noch keinen Nachteil erfahren und hatte auch keine Probleme, lasse mich aber gerne aufklären, wenn dadurch eventuell doch Einschränkungen zu erwarten sind.
ich habe mal irgendwann das hier - und ähnliche Artikel gelesen.
https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices/
Und wenn ich sehe, was tasmota aus deinen topics macht ...😳
Aber ich will da nicht Recht haben, ich bin auch nur Anfänger 😉
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

#18
@Otto123: Schöne Fundstelle!

Zitat von: traders-banquet am 10 August 2021, 13:51:35
Ich erhalte bei der Anwendung des Templates folgende Fehlermeldung :
Thx, habe eben einen Fix eingecheckt, wäre nett, wenn jemand das nochmal testen könnte (ich komme grade nicht dazu). "Gleicht" ginge es mit:
{ Svn_GetFile("FHEM/lib/AttrTemplate/mqtt2.template", "FHEM/lib/AttrTemplate/mqtt2.template", sub(){ AttrTemplate_Initialize() }) }

EDIT: für Probleme der Auflösung des BRIDGETOPC ist ein Fix im svn, ich weiß aber nicht, ob da noch mehr lauert und kann ggf. die kommenden Tage dann auch nicht helfen.

ZitatDie meisten meiner Devices habe ich selber eingetragen aber hier hat sicherlich jeder seinen eigenen Präferenzen, gefühlt geht es schneller, wenn man einen eintragen lässt, diesen dann durchkonfiguriert und wenn der Aktor dann so funktioniert, wie man es gerne hätte, dann werden die nächsten 6 in die Config eingetragen und entsprechend umbenannt, das geht viel schneller als alle dann jeweils anzupassen.
Dazu sage ich dann wieder was, wenn du den "RAW-Definitions-Weg" mal ausgetestet hast: https://wiki.fhem.de/wiki/Import_von_Code_Snippets

Das geht dann tendenziell noch schneller und man kann neben dem "copy-paste-Koonen" (z.B. genau die betroffenen!) einzelnen Devices im "Vor-attrTemplate-Zustand" wieder herstellen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

traders-banquet

Das ist ja alles sehr interessant, als Linuxer seit Suse 5.0 war ich wohl der Anlehnung an das Filesystem verfallen und hatte den führenden / anscheinend daher gesetzt. Ich werde es zukünftig weglassen.

Aktuell bin ich nicht zuhause, daher werde ich das erst morgen oder übermorgen prüfen können, ob und wie es dann funktioniert hat werde ich gerne berichten.

Vielen Dank auch für den Tip des Import von Code Snippets, das werde ich zukünftig versuchen, manchmal ist es im MC nicht immer so ganz übersichtlich.