mqtt2.template: bugs, Fragen, Anregungen

[ripperle]

Ähm, mit den Punkten? (Ging das?!?) Das könnte dann schon das Problem sein...
Nomalerweise (also bei Verwendung von autocreate und der bridge aus den templates) ist das sowas, was dann in der DEF landet: zigbee_0x90fd9ffffe0bcd51

Damit ging es jedenfalls eben bei mir mit aktuellem FHEM aus dem regulären update...
in dem von ./FHEM/lib/AttrTemplate/mqtt2.template

Nein ohne die Punkte... Aber also das hier oben eingegeben

Code Auswählen Erweitern

define zigbee_test MQTT2_DEVICE zigbee

Eingegeben und dann kann man nur eine zigbee bridge auswählen (siehe Bild) ...

[rudolfkoenig]

Ich habe gerade mit

Code Auswählen Erweitern

define test MQTT2_DEVICE zigbee...ein Geraet angelegt, und kriege jede Menge attrTemplate Moeglichkeiten.

@ripperle: ist dein FHEM aktuell? Konkret: hast du _heute_ update in FHEM ausgefuehrt?
@Beta-User: Punkte sind kein Problem, ist halt ein komisches CID.

[ripperle]

Gerade nochmal ein Update gemacht, da stand nothing to do... Dann nochmal ein Neustart von fhem und jetzt tauchen die templates auf! Seht komisch!

[Beta-User]

Gerade nochmal ein Update gemacht, da stand nothing to do... Dann nochmal ein Neustart von fhem und jetzt tauchen die templates auf! Seht komisch!

Sicher, dass du einen Neustart nach dem letzten update gemacht hattest?

@Rudi:
Danke für's Einbauen und Sorry für den Aufwand, der bis grade damit noch verbunden war.
Bin mal gespannt, wie viele Probleme damit noch aufschlagen, aber im Ergebnis finde ich das "Wegfiltern" von nicht passenden Detail-Templates mind. bei MQTT2 sinnvoll. Die templates an sich werden ja gerne angenommen, daher war das m.E. schon jetzt sehr unübersichtlich geworden.

[ripperle]

Also ich telefoniere hier parallel mit meinem Vater der das ganze bei seinem fhem Server auch machen will...

Hat auch soeben 2 mal ein Update mit anschließendem restart von fhem gemacht... Auch mal den Cache im Browser gelöscht.. Leider tauchen bei ihm immernoch nicht alle templates auf...

Irgendwie komisch 

EDIT:
KOMMANDO zurück! Es tut... Net sicher was wir falsch gemacht haben... Nochmal alles gelöscht, gesaved, und nochmal angelegt...

[TomLee]

Hallo Beta-User,

ein paar Fragen bleiben mir noch zu u.a. Template.

1. Ob nun für hier oder irgendwann mal woanders. Das Kommando besteht aus dem Befehl IRsend und den zugehörigen Parametern (bei hex, dec der JSON und bei raw einfach kommasepariert) aber getrennt durch ein Leerzeichen!
Ist es möglich mit der Parameterübergabe auch dieses Leerzeichen mitzugeben/durch ein Zeichen zu ersetzen  ?
So das der Anwender das ganze Kommando, nicht nur die zugehörigen Parameter, eintragen muss, also mit IRsend.

2. Weshalb kommen noch keine INFO.* Readings rein und schlieslich die IP nicht angezeigt ? Den ESP hab ich mehrfach neu gestartet, hab mir das von A_04b_tasmota_4ch_unified_icon abgeschaut und auch getestet das klappt, nur bei dem IR-Template noch nicht, ich sehe den Fehler nicht ?
hat sich erledigt, topic war falsch angegeben

3. 

... und am Ende Perl-Code. Gibt der undef zurück, wird der Parameter abgefragt, kann das template den Wert alleine ermitteln, wird er ohne Rückfrage verwendet.

Komm ich jetzt nicht mit. Hab das mit dem Perl Code und undef so übernommen wie du im letzten Beispiel gezeigt hast trotzdem bekomme ich (without '') nach dem Nutzerhinweis angezeigt siehe Bild im Anhang.
Es passt aber alles, es wird alles so angelegt wie gewünscht, es hat aber auch zuvor ohne Meldung alles geklappt als ich den Perl Code und undef hinter dem Nutzerhinweis noch gar nicht stehen hatte

Code Auswählen Erweitern

#tasmota device with Infrared-circuit
name:A_01d_tasmota_ir
desc:Demonstrates three options (dec, hex, raw) how to configure tasmota devices as IR remote control extension.<br><a href="https://forum.fhem.de/index.php/topic,67316.0.html">Forum Thread</a><br><a href=https://github.com/arendst/Sonoff-Tasmota/wiki/Commands#irremote">Tasmota IRremote Commands</a><br><a href="https://github.com/altelch/SonoffIR">Simple IR-circuit</a>
filter:TYPE=MQTT2_DEVICE
par:DEVNAME;ESP's name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,tele/([^/]*)/, ? $1 : undef }
par:POWERCMD;needed command to be sent like in example dec '{"protocol":"NEC","bits":32,"data":551489775}' (without '');{ undef }
par:VOLUMEUPCMD;needed command to be sent like in example raw '0,926,844,958,832,1798,868,902,848,900,870,900,852,908,918,958,794,934,874,928,1738,934,856,1764' (without '');{ undef }
par:MULTIPLE1CMD;needed command to be sent like in example hex '{"Protocol":"NEC","Bits":32,"Data":0x8166817E}' (without '');{ undef }
par:MULTIPLE2CMD;needed command to be sent like in example hex '{"Protocol":"NEC","Bits":32,"Data":0x8166817E}' (without '');{ undef }
set DEVICE attrTemplate A_01d_tasmota_ir
attr DEVICE setList \
power:noArg cmnd/DEVNAME/IRsend POWERCMD\
volumeup:noArg cmnd/DEVNAME/IRsend VOLUMEUPCMD\
11:noArg cmnd/DEVNAME/Backlog IRsend MULTIPLE1CMD;delay 8;IRsend MULTIPLE2CMD
attr DEVICE readingList \
  tele/DEVNAME/INFO.:.* { json2nameValue($EVENT) }
attr DEVICE stateFormat state\
<br>\
<a href="http://IPAddress" target="_blank">IPAddress</a>
attr DEVICE event-on-change-reading .*
attr DEVICE icon IR
attr DEVICE model A_01d_tasmota_ir

Gruß

Thomas

[Beta-User]

Moin,

Danke für das IR-template, habe ich eben leicht abgeändert eingecheckt, Test wäre nett.
Zu den Fragen:
ad 1. Keine Ahnung wg. der Leerzeichen; evtl. wäre es einen Test wert, das durch die html-Entsprechung zu ersetzten? (Vielleicht versteht der Tasmota das; im Prinzip ist es ja dieselbe Payload wie bei Steuerung via html-command)

ad 3. undef ist einfach Perl-mäßig "nicht vorhanden"; von daher war das vermutlich "overdone", was ich geschrieben habe... Das template ist jetzt  ohne das {undef} eingecheckt (das war die zu testende Änderung).

[TomLee]

Hallo Beta-User,

auf einem jungfräulichen aktuellen FHEM hab ich jetzt einfach mal einen MQTT2_CLIENT definiert, auf complex gestellt  und beobachtet wie folgende Devices angelegt:

Code Auswählen Erweitern

MQTT2_ebusd
MQTT2_ebusd_700
MQTT2_ebusd_bai
MQTT2_myMQTT2CLIENT

Bisher war es so das man auf das Sammeldevice MQTT2_myMQTT2CLIENT A_00_MQTT2_CLIENT_general_bridge mit autocreate 1 anwendete und die Geräte des Sammeldevice damit vereinzelt wurden. Wähle ich hier bei dem neuen System A_00_MQTT2_CLIENT_general_bridge aus passiert nichts, das model wird nicht übernommen, kein BridgeRegexp Attribute angelegt. Wo ist mein Denkfehler, hab ich die BridgeRegexp-Änderungen die du die Tage vorgenommen nicht richtig verstanden und das vereinzeln der Geräte geht nur noch von Hand und die General-Bridge soll gar nicht mehr verwendet werden ?

Gruß

Thomas

[Beta-User]

Hallo Thomas,
da scheint irgendwas schief zu sein. Was nutzt du als MQTT-Server? Läuft da im Hintergrund im selben FHEM ein MQTT2_SERVER (mit aktiviertem autocreate)? Darauf deutet es jedenfalls hin, dass da gleich mehrere Ebus-Devices angelegt werden...

Grundsätzlich sollte man neuerdings nicht mehr das Sammeldevice als Basis für die GeneralBridge nehmen, sondern eine Kopie und vor Anwendung des template die CID ändern (sollte auch so in den Hinweisen stehen, siehe auch den Thread zu dem speziellen template).


Zu dem IR-Dingens noch:

Evtl. kannst du noch einen setList-Eintrag generieren, der dann $EVTPART1 bis 3 (?) nutzt und die freie Eingabe von Protokoll, Bits und Data zuläßt (wäre dann ein Textfeld, alle Eingaben nur durch Leerzeichen getrennt. Damit könnte man dann das remotecontrol-Modul nutzen, ähnlich wie im Wiki beschrieben (der Artikel mit der speziellen firmware);
Wenn das klappt, wäre das m.E. sehr cool...

Wenn du da weitere Hinweise brauchst: ggf. neuen Thread aufmachen, hier verlinken.

[TomLee]

Hallo Thomas,
da scheint irgendwas schief zu sein. Was nutzt du als MQTT-Server? Läuft da im Hintergrund im selben FHEM ein MQTT2_SERVER (mit aktiviertem autocreate)? Darauf deutet es jedenfalls hin, dass da gleich mehrere Ebus-Devices angelegt werden...

Auf meinem Haupt-FHEM-Server läuft wie die ganze Zeit schon Mosquitto, deshalb nutze ich dort ja MQTT2_Client.
Wie gesagt auf dem neuen Test-System hab ich nichts weiter definiert ausser dem MQTT2_Client mit der IP:Port des Hauptserver.
Setze ich diesen auf complex werden die erwähnten Geräte automatisch angelegt, deshalb meine Frage ob das so gedacht war.

[TomLee]

Falls das was bringt, anbei ein verbose 5 Log des MQTT2_Client nachdem ich ihn von autocreate no auf complex gestellt habe und alle zuvor angelegten Geräte wieder gelöscht habe.

[Beta-User]

Wenn du von einem "jungfräulichen" FHEM sprichst, bedeutet das wirklich, dass es noch nie irgendwelche MQTT2-Geräte gab?

Ich hatte ähnliche Feststellungen auf dem einen oder anderen Testsystem, aber das lag (außer einem versehenltich parallel laufendem MQTT2_SERVER) in der Regel daran, dass ich zwar alles gelöscht hatte, aber dann FHEM nicht wieder neu gestartet. In solchen Fällen kann es scheinbar sein, dass die bridgeRegexp FHEM-intern noch gespeichert ist (die wird in einen hash gelesen).

Was (nur) hilft, wenn man auf einem "bereits genutzten System" wirklich "jungfäulich" sein will, ist autocreate am IO auszuschalten, dann alles zu löschen, save, FHEM neu starten, dann autocreate wieder an.

War es evtl. das bei dir? (andernfalls muß ich wirklich intensiver das log ansehen bzw. dann sollte das Rudi wissen...)

[TomLee]

Was (nur) hilft, wenn man auf einem "bereits genutzten System" wirklich "jungfäulich" sein will, ist autocreate am IO auszuschalten, dann alles zu löschen, save, FHEM neu starten, dann autocreate wieder an.

War es evtl. das bei dir? (andernfalls muß ich wirklich intensiver das log ansehen bzw. dann sollte das Rudi wissen...)

Danke, einen restart hatte ich nach ein / aus schalten von autocreate und löschen der Devices nicht gemacht, mit restart wird nur das eine Sammeldevice MQTT2_myMQTT2CLIENT angelegt.

[Beta-User]

...nachdem ich vorhin noch im zigbee-Thread ein Hilfsmittel zur Prüfung meiner These erhalten habe, dass intern was nicht ganz korrekt aktualisiertes verwendet wird, war ich fast sicher, dass das die Ursache war.

Danke für die Rückmeldung!

Ergänzend:
Bitte daran denken, für den "splitter", eine Kopie des "Sammeldevices" zu nehmen und erst mal die CID zu ändern.

[TomLee]

Ergänzend:
Bitte daran denken, für den "splitter", eine Kopie des "Sammeldevices" zu nehmen und erst mal die CID zu ändern

.

Ich habs jetzt begriffen  , beides, das mit dem restart und der CID sollte meiner Meinung nach hier Erwähnung finden.