MQTT2+Shelly: erste Konfiguration und template-Entwicklung

Begonnen von miggun, 03 Dezember 2018, 21:05:34

Vorheriges Thema - Nächstes Thema

87insane

Soooooooooo

Also swap geht nicht über MQTT. Ich habe nun alle möglichen Versuche gemacht....

Egal wie bescheuert die waren...
shellies/shellyswitch25-007FC8/settings/roller/0 { "swap": true }
shellyswitch25-007FC8/settings/roller/0/swap 1
shellies/shellyswitch25-007FC8/roller/0/command swap,1
shellies/shellyswitch25-007FC8/settings/roller {swap: false}
shellyswitch25-007FC8/settings/roller swap 0
shellies/shellyswitch25-007FC8/roller/command swap,0
shellies/shellyswitch25-007FC8/settings swap 0
shellies/shellyswitch25-007FC8/settings/roller/0 swap 0
shellies/shellyswitch25-007FC8/settings/roller/0/swap false
shellies/shellyswitch25-007FC8/settings/roller/0 {"swap": false}
shellies/shellyswitch25-007FC8/settings/roller/0/command {"swap": false}
shellies/shellyswitch25-007FC8/settings/roller/0/command {swap,false}
shellies/shellyswitch25-007FC8/settings/roller/0/{swap,false}


Geht alles nicht. Man kann es aber über das WEB-IF einstellen. Leider habe ich keinen anderen Weg gefunden :-\ - Bastle mal das Template

87insane

Okay !!! Sowas peinliches habe ich noch nicht gesehen.

INFO: In der neuen FW für die Shellys (Version 1.5), haben die Programmierer so einige Dinge übersehen.
- Funktion swap inputs wechselt einfach nur den Schalter. Das ist soweit okay. Aber bringt auch nur was bei falsch angeschlossenem Schalter.
- REVERSE CONTROLS
Check if you want to reverse the OPEN and CLOSE controls for the Shelly roller.
Das ist so ziemlich die schlechteste Version von umgekehrter PCT Anzeige, die ich je sah! Die PCT kommen mit dieser Option korrekt an (also für mich - 100%=geschlossen / 0%=offen). ABER - So wie es auch die Beschreibung sagt... Die Befehle und auch Ausgaben sind nun invertiert. open ist nun = close. Ich habe das betroffene Template angepasst, nur glücklich bin ich damit nicht. Es würde ohne die Funktion zu aktivieren auch mit dem alten Template weiter laufen. Ist also fragwürdig ob man das nun tauschen will:
name:A_11b1b_shelly25_roller_invert_1
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
desc:shelly25 using original firmware. <br>NOTE: shelly25 roller operated, change settings first!
par:DEVNAME;Shellyswitch25 name in the topic;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]*)/, ? $1 : undef }
attr DEVICE comment  Shelly 2.5 in Roller-Mode. 0=opened / 100=closed
attr DEVICE setList \
  open:noArg shellies/DEVNAME/roller/0/command close\
  close:noArg shellies/DEVNAME/roller/0/command open\
  half:noArg shellies/DEVNAME/roller/0/command/pos 50\
  stop:noArg shellies/DEVNAME/roller/0/command stop\
  pct:slider,0,1,100 shellies/DEVNAME/roller/0/command/pos $EVTPART1\
  x_recalibration:noArg shellies/DEVNAME/roller/0/command rc\
  x_update:noArg shellies/DEVNAME/command update_fw\
  x_mqttcom shellies/DEVNAME/command $EVTPART1
attr DEVICE readingList \
  shellies/DEVNAME/roller/0/pos:.* pct\
  shellies/DEVNAME/status/0/rollers:.* power\
  shellies/DEVNAME/online:.* online\
  shellies/DEVNAME/announce:.* { json2nameValue($EVENT) }\
  shellies/DEVNAME/roller/0:.* current\
  shellies/DEVNAME/roller/0:open {{'state' => 'closing'}}\
  shellies/DEVNAME/roller/0:close {{'state' => 'opening'}}\
  shellies/DEVNAME/roller/0/pos:.* {'state' => 100-$EVENT}\
  shellies/DEVNAME/input/1:.* input1\
  shellies/DEVNAME/input/0:.* input0\
  shellies/DEVNAME/relay/power:.* power\
  shellies/DEVNAME/relay/energy:.* energy\
  shellies/DEVNAME/temperature:.* temperature\
  shellies/DEVNAME/overtemperature:.* overtemperature
attr DEVICE devStateIcon opening:fts_shutter_up@red closing:fts_shutter_down@red true:10px-kreis-gruen false:10px-kreis-rot 100:fts_shutter_100 0:fts_shutter_10 9\d:fts_shutter_90 8\d:fts_shutter_80 7\d:fts_shutter_70 6\d:fts_shutter_60 5\d:fts_shutter_50 4\d:fts_shutter_40 3\d:fts_shutter_30 2\d:fts_shutter_20 1\d:fts_shutter_10 0\d.*:fts_shutter_10 set_.*:fts_shutter_updown
attr DEVICE cmdIcon open:fts_shutter_up close:fts_shutter_down stop:fts_shutter_manual half:fts_shutter_50
attr DEVICE webCmd :open:close:half:stop:pct
attr DEVICE stateFormat <a href="http://ip" target="_blank">\
online\
</a>\
state
deletereading -q DEVICE (?!associatedWith).*
attr DEVICE setStateList open close half stop pct
attr DEVICE model A_11b1b_shelly25_roller_invert_1


Ich musste nur close gegen open und umgekehrt einsetzen. Dafür muss aber im WEB-IF die o.g. Funktion aktiviert werden. Mit dem alten Template musste man das nicht und konnte einfach so über die Anzeige entscheiden. Ich denke, für mich ist das hier Müll! (Entscheide du @Beta-User).

Es gibt nun neue Readings im Shelly 2.5 als Rollo:
shellyswitch25_007FC8:shellies/shellyswitch25-007FC8/roller/0/power:.* roller_0_power
shellyswitch25_007FC8:shellies/shellyswitch25-007FC8/roller/0/energy:.* roller_0_energy


Diese sind nun auch wieder mit "_". Genau wie auch schon shellyswitch25_007FC8:shellies/announce:.* { json2nameValue($EVENT) }, sind diese für das Template, in meinen Augen komplett egal. Sie laufen automatisch rein wenn man autocreate an hat, aber man brauch sie auch nicht in meinen Augen. Zumindest nicht in diesem Template.

Also ist dieser Beitrag hier eigentlich nur ne Info. Habe aber auch schon ne Mail geschrieben an die Kollegen. In der Mail stehen noch einige Dinge mehr drin. Bin mal gespannt wie schnell die diesmal sind^^

@Beta-User: Kannst du bei allen shellys bitte noch x_mqttcom einbringen? Das wäre super und man kann immer direkt Befehle aus dem Device absetzen. Danke!
PS: Im Shelly 1 und Shelly 1PM habe ich keine Veränderungen erkennen können. Es gibt nichts neues was FHEM interessieren könnte.

Beta-User

Zitat@Beta-User: Kannst du bei allen shellys bitte noch x_mqttcom einbringen?
Mit dem nächsten update sollten dann bei allen Shelly-templates für sämtliche Admin-Befehle die "x_"-Präfixe verwendet werden (auch update und doRecalibration). Kommt irgenwann am WE ins svn, hoffe ich doch.

@all: Bitte ggf. nach einem update beachten, aber ich gehe mal davon aus, dass diese Befehle sowieso in der Regel "händisch" genutzt werden.

Zitat von: 87insane am 24 Mai 2019, 12:02:24- REVERSE CONTROLS
Check if you want to reverse the OPEN and CLOSE controls for the Shelly roller.
Kannst du die ggf. nochmal anpingen? Ich würde mal annehmen, dass das beim Anpassen der firmware schlicht übersehen wurde. Da das aber ggf. sehr verwirrend wird, wenn wir das hier via Template (voräufig?) drehen, würde ich das gerne erst dann anpassen, wenn die Firmware einen endgültigen Stand hat.

Die Power- und Energy-Readings lasse ich erst mal raus, die werden ja sowieso bei aktiviertem autocreate automatisch erstellt...

Grüße, Beta-User
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

87insane

Zitat von: Beta-User am 24 Mai 2019, 12:38:36
Kannst du die ggf. nochmal anpingen? Ich würde mal annehmen, dass das beim Anpassen der firmware schlicht übersehen wurde. Da das aber ggf. sehr verwirrend wird, wenn wir das hier via Template (voräufig?) drehen, würde ich das gerne erst dann anpassen, wenn die Firmware einen endgültigen Stand hat.

Hab denen schon eine Mail gesendet. Sagte ja, das es mit Abstand die billigste Umsetzung der PCT-Invertierung war, die ich je sah.
Es ist in meinen Augen so beabsichtigt von denen aber ich finde es auch eher schlecht als recht...

Die FW wird wohl in den nächsten 6-9 Monaten keinen richtigen Stand haben. Da die ja noch in relativ kleinen Kinderschuhen steckt, wird weiter und weiter entwickelt. Ich werde aber ein Auge darauf haben und berichten. Du siehst es also genauso? Also das alte Temp lassen und erst ändern wenn es korrekt implementiert wurde...

Beta-User

Na ja, in dem Fall, mag ich keine wirkliche Bewertung abgeben; ich kenne eben zwei hier geläufige Konventionen, die eine ist die HomeMatic-Variante, also offen=100% und geschlossen =0%, die andere die ROLLO-Lesart (das, was du invertiert nennst, also zu=100% und offen = 0%).
Das heißt aber nicht, dass es nicht eine weitere Variante geben könnte, ich habe allerdings noch nicht intensiv darüber nachgedacht, und m.E. sollten für unsere Zwecke (=FHEM-intern gedacht) diese zwei Sichtweisen genügen, daher werde ich das auch vorläufig lassen.
Jedenfalls solange die Shellys keine Kalibrierung (aka nicht-lineare Fahrbefehle) kennen, ist es m.E. erst mal nicht so wichtig, und evtl. haben die da auch nicht gleich verstanden, wie es gemeint war. Ist ja alles auch nicht ganz so einfach, und man hat auch nicht immer gleich viel Geduld (oder um die Ohren).

Grundsätzlich machen die Jungs da m.E. einen ganz ordentlichen Job, ist ja auch alles nicht ganz so einfach und entwickelt sich sehr schnell, da kann man schon mal einen Nebenaspekt erst mal vernachlässigen (die Invertierung in ROLLO ist aus meiner Sicht schon ein Sonderfall, zumindest HM und ZWave (Fibaro) scheinen da ein anderes Verständnis zu haben). Vielleicht solltest du darüber nachdenken, einfach insgesamt zukünftig die HM-Lesart anzuwenden? Solange es einheitlich ist, ist der WAF schnell wieder herzustellen :) . Tip noch: nimm noch einen brightness-slider für die Bedienung her, dann ist es auch für DAG's verständlich: heller = offener :) .
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

87insane

Ne neee... Soll schon so sein wie ich das mag. Es wird eben nur noch ein wenig dauern bis die das so haben, wie das sein sollte. Deswegen sagte ich ja, am besten einfach lassen wie es war. Hatte nur um es auch zu erklären mal angehangen was ich meine. So ist es etwas verständlicher...

dkreutz

Ich habe an einem Template für den Shelly RGBW2 im "color mode" gebastelt. Basiert auf dem Template für ShellyBulb mit Modifikation (RGBW2 hat keine regelbare  Farbtemperatur, dafür "Effects", etc.):

# shellyrgbw2 color mode
name:A_17a_shelly2rgbw_color
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*shellies.*
desc:shellyrgbw2 color mode <br>Tested with 1.5.0-rgbw2-hotfix1
par:DEVNAME;name of this shelly;{ AttrVal("DEVICE","readingList","") =~ m,shellies/([^/]+)/, ? $1 : undef }
attr DEVICE setList\
  off:noArg shellies/DEVNAME/color/0/command off\
  on:noArg shellies/DEVNAME/color/0/command on\
  white:colorpicker,BRI,0,1,100 shellies/DEVNAME/color/0/set {"turn":"on","white":"$EVTPART1"}\
  gain:colorpicker,BRI,0,1,100 shellies/DEVNAME/color/0/set {"turn":"on","gain":"$EVTPART1"}\
  rgb:colorpicker,RGB {$EVTPART1=~/(..)(..)(..)/;if($1 ne $2 || $2 ne $3) {"shellies/DEVNAME/color/0/set{\"turn\":\"on\",\"mode\":\"color\",\"gain\":\"100\",\"red\":".hex($1).",\"green\":".hex($2).",\"blue\":".hex($3)."}"}else{"shellies/shellybulb-3CC533/color/0/set {\"turn\":\"on\",\"mode\":\"white\",\"brightness\":".int(hex($1)/2.55)."}"}}\
  effect:select,0,1,2,3 shellies/DEVNAME/color/0/set {"effect":"$EVTPART1"}\
  update:noArg shellies/DEVNAME/command update_fw
deletereading -q DEVICE status_.*
attr DEVICE readingList shellies/DEVNAME/color/0/status:.* {json2nameValue($EVENT)}
attr DEVICE userReadings rgb:red.* {if(ReadingsVal($name,"mode","") eq "color"){sprintf("%02X%02X%02X", ReadingsVal($name,"red",99), ReadingsVal($name,"green",99), ReadingsVal($name,"blue",99))}else{my $a=sprintf("%02X",ReadingsVal($name,"brightness",0)*2.555);"$a$a$a"}}
attr DEVICE webCmd on:off:white:gain:rgb:effect
attr DEVICE genericDeviceType light
attr DEVICE icon light_control
attr DEVICE model A_17a_shelly2rgbw_color


Vielleicht mag jemand mit einem RGB2 und Farb-LED-Strip das mal testen?
Todos: "online" Anzeige wie bei dem Shelly1PM-Template, Leistungsanzeige
Raspberry Pi3B+ (Bullseye) / JeeLink868v3c (LaCrosse), nanoCUL433 (a-culfw V1.24.02), HM-MOD-UART (1.4.1), TEK603, MapleCUL / diverse Sensoren/Sender/Aktoren von Technoline, Intertechno, Shelly, Homematic und MAX!, Froggit Wetterstation, Luftdaten.info / Autor des fhem-skill für Mycroft.ai

87insane

Schaue ich mir gerne morgen an. Hab selber nicht das Teil aber den online stati kenne ich ja schon. Hab mich so viel damit geärgert. Gerne mache ich damit weiter :) schön das du dabei bist :)

Gesendet von meinem LG-H850 mit Tapatalk


Beta-User

Moin zusammen,

hab's eben als "A_17" ins svn geschoben, ohne genericType, aber mit dem Versuch eines devStateIcons.(Nur on/off; das muß aber nicht passen, Rückmeldung wäre nett...)
Wer es noch netter haben will, könnte den erweiterten 255-er-code verwenden (kann on-for-timer usw. abbilden); wer nicht umrechnen will, könnte in Color.pm schauen, da gibt es auch Dimmer-devStateIcon-Code.
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

87insane

Da war er schneller.... Danke !

Gesendet von meinem LG-H850 mit Tapatalk


Prof. Dr. Peter Henning

ZitatDie FW wird wohl in den nächsten 6-9 Monaten keinen richtigen Stand haben. Da die ja noch in relativ kleinen Kinderschuhen steckt,

Wieso das denn ? Dieses Gemaule kann ich nicht nachvollziehen, die Leute bei Allterco sind allen sinnvollen Vorschlägen gegenüber sehr aufgeschlossen und reagieren sogar innerhalb von Stunden, wenn ich einen Fehler entdeckt habe.

pah

87insane

Dem wieder sprach ich mit der Aussage auch nicht. Im Gegenteil. Trotz allem bauen die aktuell noch sehr viel ein und um. Deswegen und auch nur deswegen die kinderschuhe.

Gesendet von meinem LG-H850 mit Tapatalk


Prof. Dr. Peter Henning

"kleine" Kinderschuhe war der Ausdruck - und das ist eine vollkommen unnötige Abwertung. Ebenso wie "billigste".

Beide Bemerkungen sind innovationsfeindlich.

pah

DasQ

hat er sicherlich nicht so gemeint.

ansonsten bitte ich um eine harte, aber gerechte strafe ;-P
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

Beta-User

Ist es zu viel verlangt, wenn wir bei Gelegenheit wieder diese OT-Diskussion beenden könnten?

Es macht imo irgendwie nicht den großen Sinn, aus Anlaß einer unterschiedlichen Bewertung dessen, was eine firmware in einem speziellen Einsatzmodus unter Invertierung der vom Autor gedachten Vorgaben an Infos liefert und sich damit (möglicherweise!) nicht gleich so verhält, wie einzelne sich das vorstellen, seitenweise über als unpassend empfundene Begrifflichkeiten zu diskutieren.

Wen es interessiert hat, wird sich dazu vermutlich jetzt eine Meinung gebildet haben, wie das einzuordnen ist...

Viel eher würde mich interessieren, ob a) das devStateIcon für die rgbw-Variante funktioniert und b) ob es bessere Vorschläge gibt, die das ganze gleich in Farbe und gedimmt machen :P .
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