Hauptmenü

Status Rücklesen Dummy

Begonnen von Unen, 12 März 2020, 21:01:13

Vorheriges Thema - Nächstes Thema

Otto123

#45
Hi,

meines Wissen können Readingnamen kein Leerzeichen enthalten. Da musst Du Dir was anderes ausdenken.

Ansonsten
setreading DeinDummy DeinReadingName DeinWert

ZitatUnd wenn state auf close springt, dann soll Rollo zu den Wert 1 senden und "rollo auf wieder auf 0 schalten.
Der Rest könnte über ein UserReading gehen - in der Art:
attr RolloB userReadings RolloZu:state.* {ReadingsVal($name,'state','fehler') eq 'close' ?1:0}
Das Andere kannst Du Dir selbst basteln. ;)

Gruß Otto
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

Zitat von: ather am 19 November 2020, 17:33:36
Ich habe ein Modul dummy (RolloB) angelegt, welcher mir die Rollos über Gassistant steuert.
(ich werde immer noch wuschig, wenn ich "dummy" lese und vermute immer noch, dass das Modul ROLLO eigentlich hier der bessere Weg wäre, vermutlich kann man da auch setreading Kommandos als "Relay" hinterlegen (und dann auch Prozentwerte ansteuern (!), aber was soll's...)

Würde auch auf userReadings tippen, davon aber  zwei anlegen, die passend (und in meinem Beispiel dann auch wechselnd) getriggert werden und auch das anhalten ermöglichen sollten. Noch auf das "open/close" anzupassendes Beispiel:

defmod ot_dummy dummy
attr ot_dummy setList on:noArg off:noArg stop:noArg
attr ot_dummy userReadings auf:(on|off|stop) {return 0 if ReadingsVal($name,'state','on') ne 'on';; return 1}, zu:(on|off|stop) {return 0 if ReadingsVal($name,'state','off') ne 'off';; return 1}
attr ot_dummy webCmd on:off:stop

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

ather

#47
Zitat von: Beta-User am 19 November 2020, 17:53:29
(ich werde immer noch wuschig, wenn ich "dummy" lese und vermute immer noch, dass das Modul ROLLO eigentlich hier der bessere Weg wäre, vermutlich kann man da auch setreading Kommandos als "Relay" hinterlegen (und dann auch Prozentwerte ansteuern (!), aber was soll's...)

Hallo,
mit dem Modul Rollo habe ich es schon probiert, jedoch hat GoogleHome damit ein Problem und erkennt das Modul Rollo nicht als Rollo sondern als Dimmbare Lampe. Warum auch immer?.
Über den dummy (Type Blinds) steuere ich per Sprache und Gassistant meine Rollos.

Version von Beta-User hat funktioniert.
Wenn jetzt noch das selbstständige Rückstellung auf 0 klappt, wäre ich schon happy.
Wie kann man den Wert 1 auch selbständig zurück auf null stellen lassen, also nach ca. 1 sekunde? So dass es wie ein taster wirkt?

Vielleicht irgendein timer einbauen in Reading (z.b "at +00:00:05 set RolloAuf 0"), hs bei mir aber noch nicht funktioniert.
Also so habe ich es probiert:

RolloAuf:(open|close|stop) at +00:00:05 set RolloAuf 0 {return 0 if ReadingsVal($name,'state','open') ne 'open';; return 1}

Danke euch beiden.

Gruß
Ather

Otto123

#48
Dein Code kann so nicht funktionieren. Das muss doch Fehlermeldungen geben?

Von einer Impulsschaltung stand aber nichts in deiner Anforderung  :-\

Die Anforderung war (wenn close) dann 1 - ich halte in dem Fall die Umkehr der Abfrage (wenn nicht open) dann 1 für den falschen Ansatz. Das kann auch mal schief gehen.
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

ather

Zitat von: Otto123 am 19 November 2020, 18:57:38
Dein Code kann so nicht funktionieren. Das muss doch Fehlermeldungen geben?
Von einer Impulsschaltung stand aber nichts in deiner Anforderung  :-\

ja das stimmt er funktioniert nur so.

RolloAuf:(open|close|stop){return 0 if ReadingsVal($name,'state','open') ne 'open';; return 1 at +00:00:05 return 0},
RolloZU:(open|close|stop){return 0 if ReadingsVal($name,'state','close') ne 'close';; return 1 at +00:00:05 return 0}



Von einer Impulsschaltung stand aber nichts in deiner Anforderung
Ja Genau eignetlich benötige ich nur ein Impulse auf den jeweiligen readings.
Wie mach ich das?

Gruß
Ather

Otto123

Diese Konstrukt ist grober Unsinn!
return 1 at +00:00:05 return 0

Und über ein userReadings was sich nach einer Zeit selbst zurückstellt will ich eigentlich nicht nachdenken. :-[

Wie verarbeitest Du denn dieses Reading weiter? Mach dort den Impuls draus!
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

ather

ZitatDiese Konstrukt ist grober Unsinn!

Sorry bin in Sachen Fhem und Perl blutiger Anfänger.

Habe diesen code von dir so probiert:
RolloZU:state.* {ReadingsVal($name,'state','fehler') eq 'close' ?1:0}
RolloAuf:state.* {ReadingsVal($name,'state','fehler') eq 'open' ?1:0}


Hat aber leider nicht funktioniert. Irgendwo ist da der Wurm.

ZitatWie verarbeitest Du denn dieses Reading weiter? Mach dort den Impuls draus!

Dieses Reading leite ich weiter per MQTT-Gateway an Loxone und steuere Damit meine Rollos und alles andere auch.
Mein Problem ist nur, wenn ich das Rollo z.B  nur zur hälfte hochfahre,steht bei RolloAuf dann eine 1. Wenn ich aber dann wieder hochfahren will kann kein neuer impuls 1 kommen, da das reading ja bereits auf 1 steht. deswegen würde ich das gerne resetten.

Gruß
Ather


Otto123

#52
Ja ok - ich habe wieder nicht dran gedacht, dass es den state Event nicht gibt :)
Aber es ist egal ob Du Beta-users Code oder meinen nimmst, dass läuft aufs Gleiche hinaus - ist nur anders formuliert:
UserReadings werden mit Komma getrennt!
RolloZU:(open|close) {ReadingsVal($name,'state','fehler') eq 'close' ?1:0},RolloAuf:(open|close) {ReadingsVal($name,'state','fehler') eq 'open' ?1:0}

ZitatDieses Reading leite ich weiter per MQTT-Gateway an Loxone
Wie?

Ich verstehe das Problem noch nicht: ein close erzeugt eine 1 ein nochmaliges close erzeugt wieder eine 1 - also vom event her ist das kein Problem? Wer verhindert den?

Was ich auch nicht verstehe: Wenn es open und close gibt - wozu braucht man dann zwei Dummy Readings die jeweils für sich open in 1 und close in 1 umwandeln? Kann man das nicht direkt übersetzen? Kannst Du das gesamte Konstrukt aufzeigen - damit man das verstehen kann?
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

Nimm ROLLO, kann nicht sein, dass das nicht mit Sprachsteuerung geht! Und dann direkte Publishers mit sleep dazwischen als up down command.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

ather

#54
Zitat von: Beta-User am 19 November 2020, 19:48:14
Nimm ROLLO, kann nicht sein, dass das nicht mit Sprachsteuerung geht! Und dann direkte Publishers mit sleep dazwischen als up down command.

Habe jetzt mal ein Testrollo "ROLLO" angelegt. Leider erkennt Google Home das Ding nicht als Rollo an sondern als Dimmbare Lampe, bei der ich prozentual die Helligkeit einstellen kann.
Kein Plan warum das nicht geht. Wenn ich generictype blinds codiere, dann kann man nichts mehr steuern.

ZitatUnd dann direkte Publishers mit sleep dazwischen als up down command.

Was meinstu du damit? Wie mach ich das?

Gruß
Ather

Beta-User

Zunächst mal: ROLLO gibt es in 209 Installationen (von >5000 gemeldeten, also deutlich weniger wie hier user registriert sind) mit ca. 1200 Instanzen )= gesteuerten Rollläden; Quelle: https://fhem.de/stats/statistics.html). Ich kann mir nicht vorstellen, dass die 209 dort meldenden User alle keine Sprachsteuerung verwenden oder sich sonst niemand gemeldet hätte, wenn es ernsthafte Probleme an der Stelle gäbe. Vergiss also erst mal das mit der "Lampe", vermutlich ist es nur solange ein Problem, wie ROLLO nicht sauber eingerichtet ist. Soweit nachvollziehbar?

Das mit den publishes ist wie folgt:

Alle Client-Module zu MQTT (MQTT2_DEVICE, MQTT_GENERIC_BRIDGE, MQTT_DEVICE und ein paar Derivate mehr) haben zum Ziel, letztlich irgendwas an den MQTT-Server zu schicken, um darüber dann andere Client-Systeme entsprechend zu informieren. Schlussendlich bilden die alle einen String, der dann versendet wird. Alle MQTT-Interfaces in FHEM (00_MQTT.pm, 00_MQTT2_SERVER.pm und eben auch das von dir verwendete 00_MQTT2_CLIENT.pm) kennen daher die Option, den String auch direkt an das IO zu übergeben.
Wie, steht in der commandref:
ZitatMQTT2_CLIENT is a cleanroom implementation of an MQTT client (which connects to an external server, like mosquitto) using no perl libraries. It serves as an IODev to MQTT2_DEVICES.

[...]
Set

       
  • publish -r topic value
    publish a message, -r denotes setting the retain flag.
Ergo solltest du als erstes lernen (und uns mitteilen), wie du direkt über das IO MQTT2_CLIENT deine Relays schalten kannst.

Das kann man dann in der Kommandozeile auch mit einem sleep verbinden:
set <IODev> publish loxberry/in/Rolladen1/Auf 1; sleep 0.5;set <IODev> publish loxberry/in/Rolladen1/Auf 0

Wenn das klappt, solltest du das komplette Kommando einschl. des sleep als Attribut an das ROLLO bringen können:
attr <Rollo-Device> rl_commandUp <string = dein Kommando...>
Das hat aber mit dem global publish via MQTT_GENERIC_BRIDGE nichts zu tun (meine Empfehlung wäre immer noch, das anders zu lösen; wer auch immer diese Anleitung gemacht hat, hat vermutlich keine allzu vertieften FHEM-Kenntnisse und das ganze nicht bis zum Ende durchdacht, just my2ct.).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

ather

Zitat von: Otto123 am 19 November 2020, 19:32:05
Wie?

Ich verstehe das Problem noch nicht: ein close erzeugt eine 1 ein nochmaliges close erzeugt wieder eine 1 - also vom event her ist das kein Problem? Wer verhindert den?

Was ich auch nicht verstehe: Wenn es open und close gibt - wozu braucht man dann zwei Dummy Readings die jeweils für sich open in 1 und close in 1 umwandeln? Kann man das nicht direkt übersetzen? Kannst Du das gesamte Konstrukt aufzeigen - damit man das verstehen kann?

Also es ist ja so, dass FHEM nur dann an MQTT-Gateway sendet, wenn sich das Reading ändert bzw. ein event ändert. Wenn aber da schon eine 1 ist, und nochmals eine 1 erzeugt wird leitet Fhem/notify hier nix mehr weiter an den MQTT Gateway. Somit lässt sich das Rollo dann nur noch in die andere Richtung fahren, wenn der Wert dann wieder auf 0 springt. (event -on-change).
Oder gibt es vielleicht doch eine Möglichkeit die 1 immer auch wiederholt zu senden?(event-on-update) oder so.

Auch mit open/close habe ich das ganze schon mal realisiert, jedoch hatte ich da das selbe problem. Wenn letzter befehl close und ich mache manuell auf(per taster), lässt sich das Rollo dann per Sprache nicht mehr runterfahren, da 2xclose.

Der letzte Versuch war das ganze mit dem pct Wert zu machen. Auch da habe ich eine Möglichkeit die Soll-Position der Rollos anzugeben.(Siehe screenshot) ,aber auch da das selbe Problem. 2 x Close/open hintereinander funktioniert nicht.

Darum habe ich gedacht wenn ich 2 Impulse schicken könnte für open und close , dann könnte es funktionieren.

Gruß
Ather



Beta-User

Klingt so, als wäre da irgendwo "event-on-change-reading" gesetzt (vermutlich genauso "undurchdacht pauschal" wie das "publish alles" via MQTT_GENERIC_BRIDGE). Aber ehrlich gesagt fehlen mir hier dann list-Infos, mit denen man wenigstens wüßte, was in etwa FHEM macht.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

ather

#58
Zitat von: Beta-User am 20 November 2020, 13:32:25
Klingt so, als wäre da irgendwo "event-on-change-reading" gesetzt (vermutlich genauso "undurchdacht pauschal" wie das "publish alles" via MQTT_GENERIC_BRIDGE). Aber ehrlich gesagt fehlen mir hier dann list-Infos, mit denen man wenigstens wüßte, was in etwa FHEM macht.

Naja es wird eigentlich durch ein notify bestimmt was gesendet wird und was nicht.
So hab ich das. (Wie gesagt erstmal ohne Filter)
SYS_MQTT:cmnd:.* {
    if ($EVENT =~ qr/.*?: (.*)/p) {
        my $cmnd = $1;
        Log3($NAME, 5, "executed mqtt command: " . $cmnd);
        fhem($cmnd);
    }
}


Hier die list des RolloB. Meintest du das?

Internals:
   CFGFN     
   FUUID      xxxxxx
   NAME       RolloB
   NR         881
   STATE      pct-30
   TYPE       ROLLO
   stoptime   1605874761
   READINGS:
     2020-11-20 13:19:14   command         pct-30
     2020-11-20 13:32:36   desired_pct     42.0
     2020-11-20 13:19:14   drive-type      modul
     2020-11-20 13:19:14   last_drive      drive-up
     2020-11-20 13:19:21   pct             30
     2020-11-20 13:19:21   state           pct-30
Attributes:
   alias      Büro Rollo
   cmdIcon    open:fts_shutter_up closed:fts_shutter_down stop:fts_shutter_manual half:fts_shutter_50
   devStateIcon open:fts_shutter_10:closed closed:fts_shutter_100:open half:fts_shutter_50:closed drive-up:fts_shutter_up@red:stop drive-down:fts_shutter_down@red:stop pct-100:fts_shutter_100:open pct-90:fts_shutter_80:closed pct-80:fts_shutter_80:closed pct-70:fts_shutter_70:closed pct-60:fts_shutter_60:closed pct-50:fts_shutter_50:closed pct-40:fts_shutter_40:open pct-30:fts_shutter_30:open pct-20:fts_shutter_20:open pct-10:fts_shutter_10:open pct-0:fts_shutter_10:closed
   group      Unten
   homebridgeMapping {
  "OpenClose": {
    "reading": "state",
    "values": ["/^closed/:CLOSED", "/.*/:OPEN"],
    "cmdOpen": "open",
    "cmdClose": "closed"
  },
  "TargetPosition": {
    "reading": "position",
    "cmd": "position",
    "invert": true
  },
  "CurrentPosition": {
    "reading": "position",
    "invert": true
  }
}
   rl_autoStop 0
   rl_excessBottom 2
   rl_excessTop 4
   rl_secondsDown 35
   rl_secondsUp 35
   rl_switchTime 1
   rl_type    normal
   room       GoogleAssistant
   webCmd     open:closed:half:stop:pct


Klar du hast recht wenn das alles mal ght, werde ich später genau filtern was weitergegeben wird und was nicht. Aktuell wird per event-on change alles weitergegeben.
Habe aber auch noch nicht so viele readings.

Homebridgemapping habe ich reingemacht, da der befehl Schließen "closed" sein muss und nicht "close". So reagiert jetzt der Rollo Baustein wenigstens auf meine Sprachbefehle.


Beta-User

Nochmal: Diese notify-Lösung ist MIST! Und sie betrifft nur die von loxone an FHEM gesendeten Infos. Zuletzt ging es aber doch um die Ansteuerung einzelner Relays von FHEM aus. Das hat mit dem notify nichts zu tun, oder habe ich was verpaßt?

Was das ROLLO-Device angeht OK, das ist schon mal was. Aber da kann ich jetzt nicht erkennen, dass irgendwas per MQTT rausgeht.

(Wollte erst schreiben: "Für's erste würde ich erst mal empfehlen, außer genericDeviceType alles zu löschen, was mit Sprachsteuerung zu tun hat - oder ist die Logik jetzt doch auf der loxone-Seite?" Aber wenn es funktioniert: lass' es).

Jetzt kümmerst du dich bitte als erstes mal um den MQTT-publish für das "Antriggern" der Relays. Anders gefragt: Was erwartet deine Gegenstelle an Kommando/Signal, um einen der Ausgänge an- bzw. auszuschalten?


Und um dieses Missverständnis müssen wir uns auch nochmal kümmern:
Zitat von: ather am 20 November 2020, 13:36:46Aktuell wird per event-on change alles weitergegeben.
"event-on change" tut nichts, außer Events zu unterdrücken! siehe z.B. https://wiki.fhem.de/wiki/Event-on-change-reading

Ist zumindest an dem ROLLO aber gar nicht gesetzt...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors