MQTT2+Shelly: erste Konfiguration und template-Entwicklung

[87insane]

Wenn die älteren auch Power messung haben, haben die auch ein Power Reading.

Beispiel: shelly 1 OHNE PM = keine Messung und somit kein Reading.
Mit PM = mit Power Meter und auch dem Reading.

Im schlimmsten Fall, muss der User sein devstate anpassen.

Gesendet von meinem LG-H850 mit Tapatalk

[Mr. P]

Wenn die älteren auch Power messung haben, haben die auch ein Power Reading.

Beispiel: shelly 1 OHNE PM = keine Messung und somit kein Reading.
Mit PM = mit Power Meter und auch dem Reading.

Im schlimmsten Fall, muss der User sein devstate anpassen.

Gesendet von meinem LG-H850 mit Tapatalk

Das ist schon klar - nur haben wir keinen Älteren zum Testen.

[Beta-User]

[...] aber sofern keiner hier mit liest, der einen von der ersten Generation hat, könnte man es nur darauf an kommen lassen.

. In die Richtung hatte ich das dann auch überlegt, nachdem es hier so ruhig dazu war...

Also @all: letzte Gelegenheit zu Gegenmaßnahmen .

Reicht dir [...]

Probier mal (in einem oder mehreren der templates) die readingList vorne mit dieser Zeile zu ergänzen (oder die rL direkt zu bearbeiten, dann DEVICE entsprechend ersetzen):
shellies/announce:.* { $EVENT =~ m,..id...DEVICE...mac.*, ? json2nameValue($EVENT) : undef }\

[...] Ich habe in meinem Hinterkopf das ein sehr freundlicher Kollege hier, mal gegen das Umbiegen war

Kann ich nachvollziehen; was direkt geht, sollte man auch direkt machen, ABER:
Wenn der (vermeintlich) direkte Weg zu Nebenwirkungen führt bei anderen Nutzern, die mit den defaults arbeiten oder dort zu Verbiegungen an anderer Stelle führt, muß man eben eine Abwägung treffen. Da ich jetzt vernommen habe, dass das mit dem mapping recht einfach einzurichten ist, sehe ich überhaupt keine Probleme mit diesem "Umweg", sondern fühle mich ganz wohl mit der Bauchentscheidung (gegen deinen ursprünglichen und auch nachvollziehbaren Vorschlag).

Würde auch empfehlen, das mit den .*-on-Befehlen zu mappen und nicht manuell einzugreifen. Wie es aussieht, hat justme1968 das template-Thema "auf dem Schirm", so dass wir uns irgendwann mal über Standards zu diesem Thema Gedanken machen müssen. (und ich hatte jüngst auch eine ähnliche Diskussion mit gleichzeitigem Anschalten (bzw. Abdimmen) bei den MiLights).
Wenn also jemand bessere Ideen für eine standardisierte Benennung der setter hat: Her damit, je eher, desto besser .
Ist halt das Los, das wir jeweils gezogen haben, weil wir auf unterschiedlichen Seiten des svn sitzen .

Im schlimmsten Fall, muss der User sein devstate anpassen.

...mit so einer Aussage disqualifizierst du dich für den Anfängerbereich im Forum ...

Im Ernst: War vielleicht etwas mißverständlich gefragt, aber mir ging es nur um die Revisionen der RGBW-Devices, oder hatte ich da was mißverstanden?

[87insane]

Probier mal (in einem oder mehreren der templates) die readingList vorne mit dieser Zeile zu ergänzen (oder die rL direkt zu bearbeiten, dann DEVICE entsprechend ersetzen):
shellies/announce:.* { $EVENT =~ m,..id...DEVICE...mac.*, ? json2nameValue($EVENT) : undef }\

Und hiermit qualifiziere ich mich wieder für den Anfänger-Bereich. -> Sicherlich hattest du was im Kopf aber das kam bei mir nicht an. Ich soll rL anpassen zum testen. Das verstehe ich. Aber was ich da einsetzen soll geht für mich nicht daraus hervor. Du meinst bestimmt, das ich quasi ein ganzes Ereignis in den Bereich {} schiebe. Da brauche ich aber leider Starthilfe

Kann ich nachvollziehen; was direkt geht, sollte man auch direkt machen, ABER:
Wenn der (vermeintlich) direkte Weg zu Nebenwirkungen führt bei anderen Nutzern, die mit den defaults arbeiten oder dort zu Verbiegungen an anderer Stelle führt, muß man eben eine Abwägung treffen. Da ich jetzt vernommen habe, dass das mit dem mapping recht einfach einzurichten ist, sehe ich überhaupt keine Probleme mit diesem "Umweg", sondern fühle mich ganz wohl mit der Bauchentscheidung (gegen deinen ursprünglichen und auch nachvollziehbaren Vorschlag).

Würde auch empfehlen, das mit den .*-on-Befehlen zu mappen und nicht manuell einzugreifen. Wie es aussieht, hat justme1968 das template-Thema "auf dem Schirm", so dass wir uns irgendwann mal über Standards zu diesem Thema Gedanken machen müssen. (und ich hatte jüngst auch eine ähnliche Diskussion mit gleichzeitigem Anschalten (bzw. Abdimmen) bei den MiLights).
Wenn also jemand bessere Ideen für eine standardisierte Benennung der setter hat: Her damit, je eher, desto besser .
Ist halt das Los, das wir jeweils gezogen haben, weil wir auf unterschiedlichen Seiten des svn sitzen .

Ich habe auch nichts gegen den Weg es direkt aktiv zu schalten, wenn man an der z.B. Farbe spielt. Ohne das die LED leuchtet, weiß ich ja nicht wie diese dann genau aussehen... Selbst wenn ich das bei einigen Farbwerten weiß - WARUM sollte jemand die Farbe einstellen aber das Licht nicht? Aber gut, auch ohne Begründung schaue ich in jedem Fall mal nach dem Mapping. Das wird aber erst am WE oder in der folge Woche geschehen. Konnte bisher leider, nicht mal mehr in den Thread schauen, in dem es um das erlernen von PERL geht

Was ich verstanden habe dazu:
Du würdest die _on Befehle (nicht die Standard on Befehle) nutzen, für das Mapping. Grund, den ich verstanden habe: Ggf. Probleme mit anderen Kompatibilitäten. (Bester Grund!) - Werde mich nochmal einlesen und der Sache annehmen. Hatte ja in einem anderen Template schon daran gebastelt...

Was die Benamung der setter angeht, ist vermutlich einfach an statt on nicht erlaubt, da es wohl Wechselwirkung geben wird.
Es dürfte eigentlich kein Gerät geben, welches zwei (oder mehrfach) on benötigt. Wenn man das via Mapping "global" lösen kann, wäre das ja schon der gute Weg. Hier geht es ja tatsächlich nur darum, dass Verhalten anzupassen. Wenn man Alexa sagt "Mach das Wohnzimmer grün" und sie sagt okay, stellt die Farbe ein aber macht nichts an, macht es keinen Sinn. Das gibt es in der Art ja kaum für andere Geräte. Bei einem normalem Gerät sage ich "Mach das und das an". Dann macht sie das auch direkt.

Was ist beim MiLight Thema rauß gekommen? Hab im Bad seit x Jahren welche. Aber bisher noch nicht eingebunden, da ich das mit der Bridge so doof finde. Da warte ich mal bis es irgendwann so geht oder belasse es so wie es ist (offline mit Fernbedienung).

...mit so einer Aussage disqualifizierst du dich für den Anfängerbereich im Forum ...

Im Ernst: War vielleicht etwas mißverständlich gefragt, aber mir ging es nur um die Revisionen der RGBW-Devices, oder hatte ich da was mißverstanden?

Hey - da gibt es aber leider die meisten Antworten Den müsst ihr mir schon sperren, damit ich da nicht mehr rum weine :-P

Es gibt (soweit ich weiß) den alten RGBW1 und eben den neuen RGBW2. Der 1er wurde meines Wissens nach aber nur 2 Chargen lang verkauft. Danach wieder aus dem Programm genommen, da der 2er um einiges kleiner und besser ist. Soweit ich das verstehe (macht aber auch Sinn), sollten beide Versionen das eigentlich können. Die Technik muss ja die LEDs mit der richtigen Spannung versorgen. Aber das ist nur geraten, da (wie bereits gesagt wurde) NICHTS erkennbares im Katalog oder den Tech-Speks steht.

[Beta-User]

Und hiermit qualifiziere ich mich wieder für den Anfänger-Bereich. -> Sicherlich hattest du was im Kopf aber das kam bei mir nicht an. Ich soll sL anpassen zum testen. Das verstehe ich. Aber was ich da einsetzen soll geht für mich nicht daraus hervor. Du meinst bestimmt, das ich quasi ein ganzes Ereignis in den Bereich {} schiebe. Da brauche ich aber leider Starthilfe

...wilkommen zurück ...
Vorab: die {} sind "nur dazu da, um dem Modulcode zu sagen, dass jetzt Perl kommt. Da wird dann erst eine Regex geprüft. Da mein Code für attrTemplate war, wäre "DEVICE" durch den falschen Parameter ersetzt worden; es muß "DEVNAME" sein, also z.B. "shellyrgbw2-66138D" (aus deinem list/Eventmonitor).

Ich habe auch nichts gegen den Weg es direkt aktiv zu schalten, wenn man an der z.B. Farbe spielt. [...]

Sorry, dass ich das Farbthema immer ignoriere, aber ich kann da schlicht nicht helfen...
Vielleicht hat jemand anderes eine Idee?

Du würdest die _on Befehle (nicht die Standard on Befehle) nutzen, für das Mapping.

Ja, so war's angedacht. Für FHEM-intern "normale" Funktionsweise, für das Sprachsteuerungs-mapping (wo erforderlich) der .*_o(n|ff)-Teil .

Was die Benamung der setter angeht, ist vermutlich einfach an statt on nicht erlaubt, da es wohl Wechselwirkung geben wird.

Zum einen finde ich deutsche Benennungen in einem Softwareumfeld nicht optimal, zum anderen finde ich es einleuchtender, wenn der "eigentliche" Befehl (hier: Farbe) gut zu erkennen ist und vorne steht.

Was ist beim MiLight Thema rauß gekommen? Hab im Bad seit x Jahren welche. Aber bisher noch nicht eingebunden, da ich das mit der Bridge so doof finde. Da warte ich mal bis es irgendwann so geht oder belasse es so wie es ist (offline mit Fernbedienung).

Du könntest mit Basteln anfangen und eine sidoh-Bridge bauen; wenn du Glück hast, erkennt die auch Fernbedienungssignale... (ansonsten imo: Warnung! MiLights sind Müll, nicht kaufen...)

In der Sache: es geht darum, dass man z.B. Farbverläufe über der Zeit vogeben können soll. Das kann WifiLight (auch mit der sidoh-Bridge, aber eben über UDP) schon lange, aber WifiLight kann (noch) nicht "zusammen" mit MQTT2_DEVICE. Die Kombi bzw. eine ähnliche Erweiterung für MQTT2_DEVICE wäre auch für die anderen Bulbs interessant, die via MQTT2_DEVICE eingebunden werden können, und den WifiLight-Autor interessiert auch, wie es ggf. geht (uU. aber direkt über die firmware der sidoh-Bridge ).

Das kann aber alles dauern, das ist alles andere als trivial...

Es gibt (soweit ich weiß) den alten RGBW1 und eben den neuen RGBW2. Der 1er wurde meines Wissens nach aber nur 2 Chargen lang verkauft.

Ok, also kurz gesagt: bei einer verschwindenden Minderheit klappt das vielleicht nicht. Dann müssen die Betroffenen eben ggf. wirklich nacharbeiten...

[87insane]

...wilkommen zurück ...
Vorab: die {} sind "nur dazu da, um dem Modulcode zu sagen, dass jetzt Perl kommt. Da wird dann erst eine Regex geprüft. Da mein Code für attrTemplate war, wäre "DEVICE" durch den falschen Parameter ersetzt worden; es muß "DEVNAME" sein, also z.B. "shellyrgbw2-66138D" (aus deinem list/Eventmonitor).

Jetzt hätte ich fast ein böses Wort verloren beim lachen :-P
Das mit den Klammern usw weiß ich mittlerweile ja auch. Das wäre echt peinlich zum jetzigem Zeitpunkt, nach deinen x Erklärungen....

Bin nur etwas verwundert gewesen weil:

Code Auswählen Erweitern

shellies/announce:.* { $EVENT =~ m,..id...DEVICE...mac.*, ? json2nameValue($EVENT) : undef }
DEVICE oder DEVNAME ist klar. Finde die ganzen "..." etwas komisch. Hier dachte ich, wolltest du sowas sagen wie "usw". Aber genau das usw, kenne ich leider nicht. Hab mit den JSON bisher ja noch nie basteln müssen. Habe ja immer ein schönes Extrakt bekommen. Wie diese von innen aussehen, weiß ich, brauchte ich aber nie aktiv. Höchstens mal lesen was drin steht um ggf. Fehler zu finden.
Muss hier nur der name oder aber auch der Rest rein oder hattest du was bestimmtes im Sinn?

Sorry, dass ich das Farbthema immer ignoriere, aber ich kann da schlicht nicht helfen...
Vielleicht hat jemand anderes eine Idee?

Da bin ich mal gespannt auf eine Antwort

.*_o(n|ff)-Teil

Hatte da jemand zu wenig bit über? :-P Süßes regex

Du könntest mit Basteln anfangen....

Tatsächlich schon getan. Nur nicht mit den MiLights oder für diese. Finde die auch eher schlecht. Weswegen die keine Rolle bisher spielten. Dachte ich springe mal auf den Zug auf und frage mal. Aber meine Meinung festigte sich nur, durch deine Antwort. Wenn die durch sind, kommen andere da rein.

Bin gleich erstmal unterwegs aber habe meine Augen auf dem Thema hier. Danke @ All!

[87insane]

Ich nochmal... Habe gerade in den anderen Templates gesehen, du meinst das wirklich so mit den "..."
Verstehe ich das richtig, du willst gucken was rein läuft und wenn der Name passt, soll er alles was er findet für das Gerät einfach als Reading fest halten. Aber nur dann, wenn genau das JSON Paket rein kommt, indem auch die id, mac usw steht. Gute Idee!

Teste ich ....

[Beta-User]

Hier dachte ich, wolltest du sowas sagen wie [...]

...eigentlich wollte ich mal wieder sagen: teste es doch selbst aus, wie es gemeint war, dann hast du wieder was gelernt .

Scheint funktioniert zu haben, genau das soll passieren .

Hatte da jemand zu wenig bit über? :-P Süßes regex

Tatsächlich schon getan. Nur nicht mit den MiLights oder für diese. Finde die auch eher schlecht.

(Ganz heimlich: ich bin mit den Dingern nicht unzufrieden, habe knapp 20 von denen im Einsatz (über eine sidoh-Bridge@MQTT2). Da ich die Einschränkungen kenne, geht das in Ordnung, nur gibt's eben zwischenzeitlich zu ähnlichen Konditionen bessere Optionen.
ABER: Wenn du z.B. "einfach nur ein Input-Device" suchst, sind die Fernbedienungen kaum schlagbar . Die gibt's auch zum "an-die Wand-schrauben", in der Regel mit 4 Kanälen (bzw. eigentlich 5), die neben on/off jeweils Brightness und Farbe (als Slider oder Drehrad) und ein paar Sonderkommandos liefern (aber nur über diese Bridge!), das ganze für 20 Steine (der hier sollte z.B. funktionieren: https://smile.amazon.de/Touchscreen-Controller-Angetrieben-Batterien-Scheinwerfer/dp/B07BVTQRNN/ref=sr_1_7?keywords=milight&qid=1561469989&s=gateway&sr=8-7). 
Über die Optik mag man streiten, aber das geht eigenlich auch; bräuchte man nur noch einen Anwendungsfall für (z.B. Lautstärke in unterschiedlichen Zonen kontrollieren, Rollos fahren..., einen Montageort und Zeit und Lust ))

[87insane]

Ob es klappt oder nicht konnte ich erst jetzt testen. Geht aber! Die readings sind nach Neustart sofort (wie gewohnt) rein gelaufen. Somit kann man das ja bei allen shellys nutzen.

Was es genau macht habe ich erst gesehen, beim ansehen der json. Gut getrixt!

Kurz, weil Handy. Morgen geht es weiter. Bin nun im Off. Aber schon mal einen Teil für alle shellys wieder gefunden. Geil!

Gesendet von meinem LG-H850 mit Tapatalk

[Beta-User]

Ab morgen sollte dann via update dann

- diese regex für alle shellys kommen (ausgenommen die templates, die (noch) keine readingList hatten);
- noch mehr der .*_on-setter da sein;
- das devStateIcon für die RGBW's power beinhalten.

Frage zum ersten Punkt: da war früher mal ein announce auch auf den Device-Zweig drin. Ist der weggefallen bzw. fällt nach einem firmwareupate weg? (Dann würde ich das auch beizeiten mal rausnehmen).

Gut getrixt!

Man lernt ja schließlich nie aus; hoffe das paßt jetzt auch tatsächlich überall wie ausgerollt...


OT-EDIT: In der Bucht habe ich ein paar von den Wand-MiLight-FBs gefunden, die noch günstiger waren; da konnte ich nicht widerstehen, die von mir genannten Einsatzmöglichkeiten haben mich überzeugt, und Dimmen über einen HM-Taster geht zwar, ist aber auch nicht optimal

[87insane]

Nur kurz, da Handy...

Noch mehr von den .*_on settern. Nur im rgw2 oder wo anders? Wenn du wo anders meinst, haben wir uns Miss-verstanden. Zumindest bei den "mit mir mit erstellten" templates wird das nirgends gebraucht. Da haben wir überall eine bessere Lösung gefunden.

Den Rest muss ich leider auf morgen vertagen und beantworten.

Aber geil - danke!

Geht nicht anders... Edit: den Befehl, den du nun vermisst, checke ich morgen. Leider melden sich solche readings nicht wenn die nicht mehr kommen. [emoji44][emoji13]


Gesendet von meinem LG-H850 mit Tapatalk

[87insane]

Hey zusammen,

habe nun beim Shelly1PM getestet und das announce Reading gibt es nicht mehr... Vermutlich echt durch Update weg gefallen.
Folgende Readings bekommt man für den 1er PM:

Code Auswählen Erweitern

shellies/shelly1pm-B1D901/relay/0:.* relay_0
shellies/shelly1pm-B1D901/input/0:.* input_0
shellies/shelly1pm-B1D901/relay/0/power:.* relay_0_power
shellies/shelly1pm-B1D901/relay/0/energy:.* relay_0_energy
shellies/shelly1pm-B1D901/temperature:.* temperature
shellies/shelly1pm-B1D901/overtemperature:.* overtemperature
shellies/shelly1pm-B1D901/online:.* online
shelly1pm_B1D901:shellies/shelly1pm-B1D901/longpush/0:.* longpush_0

shellies/shelly1pm-B1D901/relay/0:.* state
shellies/announce:.* { $EVENT =~ m,..id...shelly1pm-B1D901...mac.*, ? json2nameValue($EVENT) : undef }

Das letzte hatte ich natürlich selber eingefügt am Ende (damit ich IP usw bekomme).
relay/0 zu state ist auch manuell, wegen dem Template.
Hinzu sind alle relay0 zu relay_0 geworden. Das muss im Template für z.B. den 1er PM angepasst werden. (ist hier nur für setList relevant.)

Anbei auch mal ip/status JSON:

Code Auswählen Erweitern

{"wifi_sta":{"connected":true,"ssid":"HierStehtDieSSID","ip":"192.168.20.52","rssi":-56},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":true},"time":"12:57","serial":1,"has_update":false,"mac":"840D8EB1D901","relays" :[{"ison":false, "has_timer":false,"overpower":false}],"meters":[{"power":0.00,"is_valid":true,"timestamp":1561553873,"counters":[0.000, 15.038, 0.000],"total":15}],"temperature":29.49,"overtemperature":false,"update":{"status":"idle","has_update":false,"new_version":"20190612-090006/FW1.5.0_hotfix-HT-PM@5ea70469","old_version":"20190612-090006/FW1.5.0_hotfix-HT-PM@5ea70469"},"ram_total":50856,"ram_free":39216,"fs_size":233681,"fs_free":169927,"uptime":206}

Hinzu ip/relay/0/status JSON:

Code Auswählen Erweitern

{"ison":false, "has_timer":false,"overpower":false}

Man könnte noch mehr rauß ziehen ^^ (Die Frage ist ob man das brauch).

EDIT:
Anbei die Readinglist für Shelly1 OHNE PM:

Code Auswählen Erweitern

shellies/shelly1-93ABF9/relay/0:.* relay_0
shellies/shelly1-93ABF9/input/0:.* input_0
shellies/shelly1-93ABF9/online:.* online
shellies/shelly1-93ABF9/relay/0:.* state
shellies/announce:.* { $EVENT =~ m,..id...shelly1-93ABF9...mac.*, ? json2nameValue($EVENT) : undef }

Anbei die Readinglist für Shelly 2.5 im Roller Mode:

Code Auswählen Erweitern

shellies/shellyswitch25-007FC8/online:.* online
shellies/shellyswitch25-007FC8/roller/0:.* roller_0
shellies/shellyswitch25-007FC8/roller/0/pos:.* pct
shellies/shellyswitch25-007FC8/roller/0/pos:.* state
shellies/shellyswitch25-007FC8/roller/0/power:.* roller_0_power
shellies/shellyswitch25-007FC8/relay/power:.* power
shellies/shellyswitch25-007FC8/roller/0/energy:.* roller_0_energy
shellies/shellyswitch25-007FC8/relay/energy:.* energy
shellies/shellyswitch25-007FC8/input/1:.* input_1
shellies/shellyswitch25-007FC8/input/0:.* input_0
shellies/shellyswitch25-007FC8/temperature:.* temperature
shellies/shellyswitch25-007FC8/overtemperature:.* overtemperature
shellies/shellyswitch25-007FC8/roller/0:open {{'state' => 'closing'}}
shellies/shellyswitch25-007FC8/roller/0:close {{'state' => 'opening'}}
shellies/announce:.* { $EVENT =~ m,..id...shellyswitch25-007FC8...mac.*, ? json2nameValue($EVENT) : undef }

Anbei auch nochmal Shelly 2.5 ip/status JSON:

Code Auswählen Erweitern

{"wifi_sta":{"connected":true,"ssid":"HierSSID","ip":"192.168.20.34","rssi":-62},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":true},"time":"13:47","serial":1,"has_update":false,"mac":"2462AB007FC8","relays":[{"ison":false,"has_timer":false,"overpower":false,"overtemperature":false,"is_valid":true},{"ison":false,"has_timer":false,"overpower":false,"overtemperature":false,"is_valid":true}],"rollers":[{"state":"stop","power":0.00,"is_valid":true,"safety_switch":false,"overtemperature":false,"stop_reason":"normal","last_direction":"open","current_pos":85,"calibrating":false,"positioning":true}],"meters":[{"power":0.00,"is_valid":true,"timestamp":1561556859,"counters":[0.000, 0.000, 0.000],"total":15},{"power":0.00,"is_valid":true,"timestamp":1561556859,"counters":[0.000, 0.000, 0.000],"total":11}],"temperature":74.61,"overtemperature":false,"update":{"status":"idle","has_update":false,"new_version":"20190531-075825/v1.5.0-hotfix2@022ec015","old_version":"20190531-075825/v1.5.0-hotfix2@022ec015"},"ram_total":49600,"ram_free":36712,"fs_size":233681,"fs_free":153612,"uptime":1879}


Anbei die Readinglist für Shelly RGBW 2 im Color Mode:

Code Auswählen Erweitern

shellies/shellyrgbw2-66138D/online:.* online
shellies/shellyrgbw2-66138D/color/0/status:.* { json2nameValue($EVENT) }
shellies/shellyrgbw2-66138D/color/0:.* state
shellies/announce:.* { $EVENT =~ m,..id...shellyrgbw2-66138D...mac.*, ? json2nameValue($EVENT) : undef }

Anbei auch nochmal RGBW2 ip/status JSON:

Code Auswählen Erweitern

{"wifi_sta":{"connected":true,"ssid":"HierSSID","ip":"192.168.20.54","rssi":-90},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":true},"time":"13:31","serial":1,"has_update":false,"mac":"B4E62D661CD3","mode":"color","input":0,"lights":[{"ison":false,"mode":"color","red":72,"green":255,"blue":237,"white":0,"gain":100,"effect":0,"power":0.00,"overpower":false}],"meters":[{"power":0.00,"is_valid":true}],"update":{"status":"idle","has_update":false,"new_version":"20190531-080138/v1.5.0-hotfix2@022ec015","old_version":"20190531-080138/v1.5.0-hotfix2@022ec015"},"ram_total":50464,"ram_free":37776,"fs_size":233681,"fs_free":156122,"uptime":181046}

Und RGBW2 ip/color/0/status JSON:

Code Auswählen Erweitern

{"ison":false,"mode":"color","red":72,"green":255,"blue":237,"white":0,"gain":100,"effect":0,"power":0.00,"overpower":false}

Also ist in allen Shellys das Template minimal an zu passen. Das sind aber wirklich nur Kleinigkeiten. Denke mal das machst du so @Beta-User. Aber schön das die Shelly Kollegen mal aufgeräumt haben



Zum Thema MiLight, melde ich mich ggf. mal so - Ist hier aber ja eh OT

- noch mehr der .*_on-setter da sein

Wo denn überall?

Gruß,
Kai

[Beta-User]

Hmm, dann also:

Die alten announce-Pfade fliegen wohl zeitnah überall raus... (? bitte "wehren", wenn das jemand anders haben will!)
Die regex für die neuen sollte schon passen (wen's im Detail interessiert: bitte im svn nachsehen; da steht auch, welche .*_on eingefügt wurden (sollten die letzten 2 oder 3 commits auf das file sein) ). Wenn ich da (regex) falsch liegen sollte: bitte zeitnah um Info...

Was das Format relay_0 usw. angeht: "Muß" ist vielleicht etwas stark formuliert, aber vielleicht macht das Sinn (nur ziemlich sicher nicht "gleich"):- Funktionieren wird das auch mit den seitherigen Reading-Namen (die neuen werden seit einiger Zeit durch autocreate anders erstellt als früher);- Ändere ich die jetzt, bekommen alle, die "nur" an den neuen "announces" interessiert sind, ihre "alten" Readingnamen nicht mehr befüllt, sondern die neuen... MaW: das wäre für diese Nutzergruppe ein "breaking change";
- Für alle, die ab jetzt (bzw. eigentlich seit längerem) in das Thema einsteigen, ist es grade anders rum: Da wurde bisher anders benannt, als autocreate das seit einiger Zeit macht, was bedeutet, dass ggf. deren ältere Daten besser verwertbar bleiben, wenn man's jetzt umstellt.
- Was relay_0_power etc. angeht, finde ich diese Benennung unschön (autocreate macht das aus guten Gränden (!) aber so...).

MaW.: hier wäre insgesamt die Frage, was gewünscht wird (ich habe die Dinger nicht, mir im Prinzip egal, ob wir da eben die autocreate-Benennung nehmen oder eine Kurzbezeichnung und damit das bisherige System beibehalten...)
Meine Tendenz: eigentlich finde ich die Kurzbezeichnungen ganz ok, und das Mittel attrTemplate ist zwischenzeitlich auch soweit geläufig, dass es von der Mehrheit als Teil der Ersteinrichtung genutzt werden dürfte. Damit hat man keine/wenig Inkonsistenzen (und wenn, ist derjenige "selber schuld"  ) => würde es einfach lassen, wie es (jetzt in den templates) ist!?


Bitte um zeitnahe Info und Argumente (außer: autocreate verfährt anders), wenn jemand das anders sieht...

[87insane]

Hey Beta-User,

habe meinen Beitrag nochmal editiert und alles was ich bieten kann, rein geschoben.

Ich bin der Meinung, dass die autocreate Namen verwendet werden sollten. So ist es immer sauber und es fällt im Fehlerfall eher auf. Hinzu werden diese ja bei Inbetriebnahme direkt so auch angelegt (autocreate). Es ist für neue User aus meiner Sicht, einfacher zu verstehen. Warum einen Namen ändern der eigentlich alles sagt. Man weiß nicht wie sich Shelly entwickeln wird aber im schlimmsten Fall belegen wir mit einer kurz-Bezeichnung nur einen Slot und haben am Ende eine Wechselwirkung (dein liebstes Argument :-P).

Die Regex passt bei mir, für jeden Shelly (FW 1.5.0). Super das Ding

da steht auch, welche .*_on eingefügt wurden

Ist das wieder das Los, welches ich gezogen habe bezüglich der Seite des SVN? Ich suche hier alles zusammen und du kopierst, dass was du auf deinem Desktop hast, nicht eben hier rein... Wo ist der heulende Smilie

Für alle die ein aktuelles Template über einen alten Shelly bügeln (FW Version), macht das eh keinen Sinn. Ich würde wenn dann:
A: Gerät sauber neu anlegen
oder
B: In die Template Datei sehen und den benötigten Teil rauß kopieren.

Generell würde ich mir das immer vorher einmal ansehen. Es ändert sich fast täglich etwas und ich kann ja nicht immer alle Threads durch blättern.

Gruß

[Beta-User]

Vorab mal Danke für deinen Eifer!

Was die jeweilige "Seite von svn" angeht: Woher willst du wissen, was ich auf meinem Desktop habe?!? Wenn ich Änderungen "von irgendwo" her bei irgendeinem FHEM-Ding nachvollziehen will, nutze ich häufig https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/. Da kommt man mit ein paar Klicks von fhem.de her hin und kann alles möglich an Änderungen nachsehen .

Und weil es eigentlich so sein sollte, dass man neue template-Versionen "einfach so" über bereits mit diesem Mittel konfigurierte Devices anwenden können sollte, ändere ich da ungern was so grundlegendes wie die sich ergebenden Readingnamen. Als autocreate da geändert wurde, gab's schon mal Überlegungen, diese (neuen) Namen zu nutzen. Das Ergebnis war, dass die autocreate-Readings schlicht gelöscht wurden, damit sie niemanden mehr verwirren .
Davor war - soweit ich mich entsinne -  die letzte grundlegende Änderung, die Kanäle binär zu mappen (ursprünglich war das, was über "0" kam auf "relay1" gemappt), und alle mehrkanaligen Devices haben auch eindeutige Readingnamen (nur eben kürzere), aus denen abzulesen ist, wozu sie gehören. Das Konsistenzargument scheint mir damit ein wenig schlagkräftiges zu sein.

Anders gesagt: Du bist seit mehreren Monaten der erste, der sich daran stört, dass autocreate und die templates hier nicht dasselbe tun.

Wenn jetzt mehrere kommen und sagen, dass sie das schon immer nicht gut fanden, denke ich ernsthaft über eine Änderung nach, ansonsten bewerte ich die weitere Ruhe als Zustimmung zu meiner Tendenz .