Rolladensteuerung, Abfrage auf / zu mit 2 Variablen

Begonnen von B.Stromberg, 29 August 2018, 07:46:31

Vorheriges Thema - Nächstes Thema

Beta-User

#15
Ich habe die Dinger nicht und kann daher nur versuchen, hier mein Verständnis dessen darzustellen, was ich lese:

Wenn du die FB (Wandselner?) betätigst, die zu dem Wohnzimmer-Rolladen "gehören", aktualisiert sich das Reading "serial_rx" (z.B. auf 0045f500). Das ist dann im Wohnzimmerrolladen als "remote_serial"-Attribut anzulegen, also:

attr WohnzimmerTuer remote_serial 0045f500
Mehrere FB's, die zu dem Device gehören, werden mit Komma getrennt (ohne Leerzeichen!), also z.B.
attr WohnzimmerTuer remote_serial 0045f500,87654321
Zu jedem Rolladen ist/sind also jeweils "seine" FB(s) als Attribut zu hinterlegen ;) .

Die spannende Frage wird dann sein, ob sich nach dem Setzen des Attributs im derzeit empfangenden Device das Reading auch bei einem weiteren Rolladen einstellt, oder ob weiter alles beim Channel-1-Device landet.

EDIT: der Modulautor hat doch an der von dir verlinkten Stelle auch in Deutsch beschrieben, wie es geht; man muß auch das disc-Attribut sowie ggf. weitere Attribute (group_serial) setzen... [/EDIT]

Das mit den verlorenen Messages würde ich auf den ESP-Code bzw. UDP zurückführen; das ist einfach eine unzuverlässige Art der Verbindung. Abhilfe schafft ggf. ein regelmäßiger Ping auf den ESP (alle 2 Min. oder so); da hat Cooltux vermutlich mehr Ideen zu...

"Modul" ist doppeldeutig: im letzten Beitrag von B.Stromberg scheint eher eine verbaute Hardware gemeint zu sein mit der Möglichkeit, mehrere Rolladen/Markisen konkret anzusteuern. Davon hat er 2?
Ich meinte bislang immer das Perl-Modul für FHEM.
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

CoolTux

Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

B.Stromberg

Oh oh oh...
Jetzt habe ich ja was losgetreten ;)

Also zum einen meinte ich mit Modul den / die Empfänger, sorry für das Missverständnis!

Ich habe hier 10 Rohrmotoren des gleichen Fabrikats, mit dem selben Empfänger.
Nur meine Markise hat einen anderen.

Readings bekomme ich bei den 10 Rohrmotoren nur auf Channel1 (1-16 möglich) und bei dem Empfänger der Markise.

Wohl nächstes Missverständnis:

Die serial_rx im Reading ist wohl eher die besagte Serial von der ansteuernden Funk Fernbedienung.
Der Empfänger/Rohrmotor ist dann das Reading Disc_l_h.

Der Text im Blog ist etwas verwirrend, weil der Ersteller der Module (FHEM und *.ino) hier und da etwas aktuallisiert hat und sich somit ältere Dinge aufgehoben haben. (Diese wurden im 1. Beitrag aber wohl nicht gelöscht)

Konnte jetzt im Blog eine Nachricht hinterlassen und habe hier auf meinen Beitrag verwiesen.
Evtl. kann der Entwickler der Hard und Software uns hier weiterhelfen.
Allerdings hat dieser sich im Blog schon längere Zeit nicht mehr gemeldet...

Wäre sehr schade, wenn dies nun alles einschläft...

Beta-User

Vielleicht meldet sich der Entwickler, vielleicht aber auch nicht :D .

Jedenfalls hat er am Ende des ersten Beitrags diese Attribute in einem zusammenhängenden Nachtrag erläutert. Es macht daher Sinn, zunächst mal dieser Anleitung zu folgen, oder?

Anmerkung: Wie Entwickler denken, kannst du in dem Link aus hier nachlesen; vielleicht hilft dir das zu verstehen, warum er sich ggf. meldet oder eben nicht ;) .
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

B.Stromberg

Ja ok, das habe ich nun getan.

Alles ist so angelegt wie beschrieben:


Internals:
   CONNECTS   1
   DEF        1 192.168.2.27 4210 4211
   FD         13
   NAME       WohnzimmerTuer
   NR         127
   STATE      up
   TYPE       jarolift
   channel    1
   ip         192.168.2.27
   port       4210
   remoteport 4211
   READINGS:
     2018-08-29 12:59:39   Disc_l_h        1000001000000001
     2018-08-29 12:00:21   reboot          Reboot done
     2018-08-29 12:59:39   rssi            103
     2018-08-29 12:59:39   rx_function     04
     2018-08-29 12:59:39   serial_rx       0045f500
Attributes:
   disc       0010000011110101
   icon       fts_shutter_updown
   remote_serial 0045f500
   room       Jarolift
   webCmd     up:stop:down:shade:learn


STATE wird trotzdem nicht aktuallisiert wenn ich auf den Wandsender klicke...

Tja, da drehen wir uns nun im Kreis
Schade...

Ähm

help jarolift bringt nicht wirklich eine Ausgabe in FHEM, normalerweise mein erster Anlaufpunkt

CoolTux

Das Modul besitzt keine Commandref daher kommt nichts bei help. Das Modul wurde für den eigen Zweck entwickelt und mal eben schnell nach Bedarf zusammengeschuhstert. Da kann man nicht viel erwarten. Der Entwickler wird sich denken für mich passt es.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

Na ja, einen Versuch war es wert.

Irritiert bin ich aber, weil bei dir
Zitat2018-08-29 12:59:39   Disc_l_h        1000001000000001
2018-08-29 12:00:21   reboot          Reboot done
2018-08-29 12:59:39   rssi            103
2018-08-29 12:59:39   rx_function     04
2018-08-29 12:59:39   serial_rx       0045f500
steht, aber
Zitatdisc       0010000011110101

Eigentlich sollte das nach meinem Verständnis anders sein, siehe die Anleitung:
ZitatDas Reading disc_l_h kopiert ihr ins Attribut disc.
Wäre 1:1, ohne irgendeine Art der Umformung...

Zitat von: CoolTux am 29 August 2018, 13:49:09
Das Modul besitzt keine Commandref daher kommt nichts bei help. Das Modul wurde für den eigen Zweck entwickelt und mal eben schnell nach Bedarf zusammengeschuhstert. Da kann man nicht viel erwarten. Der Entwickler wird sich denken für mich passt es.
Vermutlich hätte der Autor gerne ein "vernünftiges Modul" gemacht, allerdings gab es da 2013 eine Diskussion wg. rechtlicher Bedenken hinsichtlich des Keys zur Entschlüsselung der Nachrichten. Und viele andere scheinen nicht diese Probleme zu haben wie der TE, der vorhandenen Anleitung zu folgen...

@TE zur Ergänzung: Solange es kein offizielles Modul ist, darf der Entwickler die Doku machen, wie er will ;) . Commandref in Englisch ist nur bei Veröffentlichung via svn Pflicht.
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

exciter

Genauso habe ich es auch für meine Zwecke geschrieben ;-)  Zweistufig wäre besser, aber ich wollte damals schnelle Ergebnisse und deswegen ist es auch so dahingeschustert. Ich werde die Tage nochmal reinschauen. Habe seitdem auch nix weiter geändert...der Empfang war mehr experimentell. Ich melde mich...

Gruß Steffen

B.Stromberg

Zitat von: Beta-User am 29 August 2018, 13:55:21
Na ja, einen Versuch war es wert.

Irritiert bin ich aber, weil bei dirsteht, aber
Eigentlich sollte das nach meinem Verständnis anders sein, siehe die Anleitung:Wäre 1:1, ohne irgendeine Art der Umformung...

Ja, nur solange auf dem Channel 1 des Devices SÄMTLICHE Readings auflaufen von den anderen 9 Devices, kann das Reading von List schonmal abweichen.

Und im Moment gibt es auf Channel 1 der Rohrmotoren gar keine Readings mehr, weil diese beim Device Markise (das mit dem Empfänger für Markisen) aufläuft.

Für das Device WohnzimmerTuer (das von dir gerügte) sieht das Reading dann so aus:


READINGS:
     2018-08-29 14:33:10   Disc_l_h        0010010000000001
     2018-08-29 14:21:09   reboot          Reboot done
     2018-08-29 14:33:10   rssi            110
     2018-08-29 14:33:10   rx_function     04
     2018-08-29 14:33:10   serial_rx       0045f500


Das sollte nun passen.

Ich würde mich freuen, wenn Steffen hier mit den Cracks ein wenig fachsimpeln würde und wir so ein schönes Modul für FHEM basteln könnten.

Wegen der rechtlichen Bedenken:
Die beiden benötigten Keys sind nicht im FHEM Modul enthalten! Diese werden auf die Steuerhardware geflashed.

@exciter
Steffen, hast du denn bei dir in FHEM die Readings ordentlich laufen? Also wird der STATE unabhängig vom ausführenden Sender geändert?
Vielleicht bin ich ja wirklich nur zu doof  :'(




Beta-User

Ok, sorry wg. der Irritation.
Das mit dem Hinweis auf die key-Frage war nur als Hinweis gemeint, dass es ehrenhafte Gründe gab, die Entwicklung außerhalb von FHEM (bzw. auch der culfw) weiterzuführen, zumal das Perl-Modul ohne die firmware keinen großen Sinn macht.
Scheint wirklich so zu sein, dass der "Rückweg" eher experimentell ist, wenn jetzt plötzlich alles auf dem anderen Device aufläuft.

Ich gehe mal davon aus, dass du das Markisen-Device im Verlauf des Threads neu definiert hattest? (Das würde dann für die Annahme sprechen, dass das letzte Device in der fhem.cfg mit Channel 1 sich alle Daten von der IP:Port-Kombi schnappt, und andere Devices davon nichts mehr haben...).

Da ich aber - wie gesagt - keine solche HW habe, kann ich vermutlich ab hier nichts mehr zielführendes beitragen; wäre schön, wenn es bald eine für dich und ggf. andere sinnvolle Lösung geben würde.

@exciter: Da die firmware scheinbar auch MQTT spricht noch eine Frage: Wäre es evtl. nicht einfacher, mit den neuen MQTT2-Modulen zu arbeiten?
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

B.Stromberg

@Beta-User

Ja, exakt, ich hatte die Markise erst später angelernt, was dafür spricht, dass die Readings immer nur beim zuletzt angelernten Gerät auflaufen.
Bei dem von mir genannten Channel 1 Gerät (WohnzimmerTuer) kommt seitdem nichts mehr an.
Die Readings über MQTT zu bekommen wäre ein Träumchen.

Wenn Steffen möchte, würde ich mich sehr freuen, wenn man hier zusammen im FHEM Board mit den DEVS ein optimiertes Modul zusammenklöppelt. :)



Reliktdragon

Hallo.

Ich habe auch diese Lösung von bastelbude. Den msb und Lsb habe ich soweit alles im Sketch.
Ich sehe im log von esp das die Befehle aus Fhem und die von der Jarolift Fernbedienung erkannt werden.
Leider ist es mir aber nicht möglich die Rollläden anzulernen.
Kann mir da jemand helfen wie ich das hinbekomme?

Hab die Motoren im anlernmodus, drücke in Fhem auf learn. Es passiert aber nix.

Grüße

B.Stromberg

Lies in dem Bastelbudenbuben Thread mal weiter.... Und guck dort speziell nach dem Wort "Packetsender "

Sollten die Keys die du hast richtig sein, hilft dir das dann hoffentlich weiter

Reliktdragon

Zitat von: B.Stromberg am 30 Dezember 2018, 20:03:13
Lies in dem Bastelbudenbuben Thread mal weiter.... Und guck dort speziell nach dem Wort "Packetsender "

Sollten die Keys die du hast richtig sein, hilft dir das dann hoffentlich weiter

Vielen dank. Die Motoren funktionieren nun wunderbar.

Ich habe an zwei fenstern nun aber noch jeweils einen TDRR 01W. Bei einem davon wurde das anlernen vom Motor bestätigt. Fahren kann ich diesen rolladen aber leider nicht. Muss ich bei einem TDRR 01W noch etwas ändern?

B.Stromberg

Tja so ein Teil habe ich leider nicht, ich habe nur die Rohrmotoren, wo der Funkempfänger direkt verbaut ist im Motor.
Alledings habe ich noch eine Markisensteuerung von Jarolift, die geht mit FHEM ebenfalls...

Sehe eigentlich keinen Grund, warum die TDRR 01W nicht gehen sollten. Geh mal mit einer Fernbedienung auf den Kanal vom TDRR 01W, welche damit funktioniert.
Drück 8 x die Stopptaste (Funktion zum kopieren des Funkcodes, evtl. anders beim TDRR 01W)
Gibt der Empfänger dann eine Rückmeldung (bei den Rohrmotoren laufen die kurz vor und rückwärts) in FHEM anlernen clicken...

Evtl. auch mal die Anleitung vom TDRR 01W lesen und ALLE angelernten Codes löschen (falls möglich)