FHEM Forum

CUL - Entwicklung => Wunschliste => Thema gestartet von: memed am 22 Juli 2016, 11:23:41

Titel: Neues Modul für REV Ritter iComfort
Beitrag von: memed am 22 Juli 2016, 11:23:41
Hallo,

nach etwas Arbeit ist es mir gelungen das Netzwerk-Gateway von iComfort zu verstehen. Kommandos, Statusmeldungen und Parameter sind grundsätzlich verstanden, auch Dimmer-Funktionen oder Zeitpläne setzen klappt. Es fehlen Details zu Rolloschaltungen (habe keine) und manche Besonderheit ist sicherlich noch unbekannt.

Mit shellskripten ist die Steuerung schon halbwegs möglich aber an einer Umsetzung mit Php oder Perl möchte ich mich nicht alleine versuchen.
Evtl. hat ja jemand Lust anhand einer Protokolldefinition zu helfen ein FHEM Modul für iComfort zu bauen - ich würde sogar hoffen, dass nur ein vorhandenes Modul umgemodelt werden muss...

Hier sind die Infos zum Protokoll: http://pastebin.com/3Jv6Rpjf

Ich könnte bei ernsthaftem Interesse auch ein Lan-Gateway und ein Gerät leihweise zur Verfügung stellen falls jemand Lust aber kein Gerät hat.

Viel Spass am Geraet
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: rastagandalf am 06 November 2016, 21:48:32
Gibt es da inzwischen was neues?
Hab so ein Ding bekommen, leider ohne Fernbedienung, aber FHEM könnte das ja übernehmen...sonst bleibts erstmal in der Haustechnikkiste...
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 21 November 2016, 10:43:28
Hallo Zusammen,

Habe mir mal die Mühe mit eiem zweistufigen Modul für das REV Gateway 86500-B gemacht. Gateway anlegen über define <Name> REVICOMFORT <IPAdresse>. wenn danach die Learntaste an den Schaltern für drei Sekunden gedrückt wird, werden die Clients angelegt.

Näheres auch im HTML Bereich der Dateien.

Vielleicht schaut auch mal Rudolf oder Markus über die Programmierung.

Über Feedback würde ich mich freuen.
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: rudolfkoenig am 21 November 2016, 11:33:07
Grob druebergeschaut, was mir auffaellt:
- REVICOMFORT_Set: Befehle wie "set dev close no" macht nichts, und es kommt mir, als Benutzer merkwuerdig vor. Wozu ist yes/no notwendig?
- Beide DeleteFn Funktionen: wo wird die Datei angelegt, was hier geloescht wird?
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 21 November 2016, 14:26:15
Hallo,

Die Delete Funktion nehme ich heraus.
Wie setzt man my %devices = ("open"       => "yes,no"); ohne das ein Textfeld hinter der Auswahlliste erscheint?

Danke fürs durch schauen.
Gruß
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: rudolfkoenig am 21 November 2016, 14:56:15
"open" => "noArg"

Siehe auch commandref Doku zu widgetOverride.
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 21 November 2016, 16:55:06
Hallo,

Hier nun die geänderten Dateien.

Danke für die Infos.
Gruß
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: siddyfly am 20 Dezember 2016, 22:09:30
hi habe heute das Modul mal reinkopiert und fix die config angepasst.
Funktioniert :D ;D.
Klick auf Fernbedienung Licht geht an und FHEM zeigt es.
Klick FHEM und Licht geht aus incl Statuswechsel in FHEM.
Und umgedreht.
Super.
Hatte schon via Perlscript gebastelt. Das Modul hier ist jedoch besser.
Danke an den Entwickler.
Ich werde später definitiv mehr Feedback geben.
Hab auch noch einen Weg wie man schnell alle devices abfragen kann via Perl.
Das spart das rumsausen durchs Haus.
Reiche ich nach, muss das Skript noch anpassen.
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 22 Dezember 2016, 19:41:59
Hey,

schön, das es Dir gefällt.
Habe diese Woche den Dimmer dazu erhalten. Werde es zeitnah einpflegen und dann hier wieder einstellen.
:)
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: siddyfly am 28 Dezember 2016, 16:26:40
hier das kleine script mit dem man alle geräte auslesen kann.
Ich hoffe das geht bei euch, ich hab einen Raspi am laufen.
Somit bleibt das große krabbeln und das Öffnen der Unterputzdosen aus. Ihr müsst nur die IP Adresse im Script anpassen.


In die fhem.cfg hab ich es so eingebaut.

#REV ICOMFORT definition LampeKueche 00011511
define REVI_00011511 REVI 00011511
attr REVI_00011511 IODev ICOMFORT
attr REVI_00011511 alias LampeKueche
attr REVI_00011511 devStateIcon on:black_FS20.on:off off:black_FS20.off:on
attr REVI_00011511 room Wohnzimmer
define FileLog_REVI_00011511 FileLog ./log/REVI_00011511-%Y.log REVI_00011511
attr FileLog_REVI_00011511 logtype text
attr FileLog_REVI_00011511 room logfiles


Viele Grüße
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 28 Dezember 2016, 21:23:13
Hey, super

werde versuchen den Befehl mit im Gateway aufzunehmen. Bin gerade bei den Dimmern.
Den Befehl kannte ich noch nicht . Danke
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: memed am 22 Januar 2017, 23:18:33
Vielen Dank für die Arbeit am Modul!
Ich werde das die Woche mal alles auf einer Synology installieren wenn alles gut geht.
Zu den Dimmern noch ein Tipp: die Dimmer brauchen kein Abschluss-Zeichen (\n) im Befehl, da wird mit übermitteltem Hex-Wert direkt geschaltet.
Die Dimmer sind aber eh etwas tricks, da ist bei 100% nicht der gleiche Strom anliegen wie bei einem Switch - der DImmer ist immer noch ein bisschen aktiv und moduliert die Phase. Bei 0% ist auch nicht ganz aus. Ich habe einen Mückenstecker der bei 0% noch fröhlich flackert und bei 100 nicht ganz leuchtet....

Gruß -M
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 24 Januar 2017, 18:25:20
Hallo,

Anbei eine neue Version. Nun sind die Dimmer mit drin.

Zwei Dinge, die mir richtig Kopfschmerzen bereiten,sind:

Die Dimmfunktion Up oder Down geht im Moment immer nur einen Wert weiter. Ich würde gerne kontinuierlich weiter dimmen und dann mit set dimstop , das ganze stoppen. Also einen Loop aufrufen, aber im nächsten Schritt mit dimstop das Script nochmal aufrufen. Und genau das brachte alles zum Absturz. Vielleicht gibt es hier irgendeine Lösung , die mir bislang noch nicht bekannt ist.

Bei der Definition werden jetzt zwei Werte in die Def geschrieben. Dieses zu trennen und den Typ des Devices in {Typ} zu schreiben gelang mir überhaupt nicht.
Mit ParseParams habe ich experementiert, habe aber nur die Hash Referenz sehen können, und nicht die Rohdaten. Vielleicht auch hier von Euch eine Idee.

Gruß ELW
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: memed am 25 Januar 2017, 01:48:35
H,

ich habe scheinbar noch PRobleme mit der Umgebung (Synology x86 NAS mit aktuellem FHEM, update erfolgreich durchgeführt).
Bei jedem Senden eines Befehls crasht FHEM.
Hier die Logmeldung zum Aurodiscover und zum Crash:
2017.01.25 01:38:22 0: Featurelevel: 5.7
2017.01.25 01:38:22 0: Server started with 13 defined entities (fhem.pl:13142/2017-01-18 perl:5.024000 os:linux user:fhem pid:25960)
2017.01.25 01:40:08 3: REVI  (ICOMFORT)  - Vorschlag to defined UNDEFINED REVI_001627c1 REVI 001627c1 84462
2017.01.25 01:40:08 2: autocreate: define REVI_001627c1 REVI 001627c1 84462
2017.01.25 01:40:08 2: autocreate: define FileLog_REVI_001627c1 FileLog ./log/REVI_001627c1-%Y.log REVI_001627c1
2017.01.25 01:40:47 1: PERL WARNING: Use of uninitialized value $REVTyp in string eq at ./FHEM/79_REVI.pm line 211.
2017.01.25 01:40:47 1: PERL WARNING: Use of uninitialized value $REVTyp in string eq at ./FHEM/79_REVI.pm line 215.
2017.01.25 01:41:08 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/92_FileLog.pm line 437.
2017.01.25 01:41:30 3: REVICOMFORT (ICOMFORT) - sending data: S?d=00&a=001627c1
Can't use string ("1/8") as a HASH ref while "strict refs" in use at /usr/local/fhem/opt/fhem.pl line 3566.

Ich komme da nicht weiter, evtl. Tipps was ich machen kann?
Gruß -M
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 25 Januar 2017, 20:10:56
Hallo,

Du hast recht, Sorry, da ist mir ein Fehler unterlaufen. Jedenfalls das mit dem REVTyp ist weg. Warum:

Can't use string ("1/8") as a HASH ref while "strict refs" in use at /usr/local/fhem/opt/fhem.pl line 3566.

kommt.....????

Zum Schluss habe ich die Kodierung der  Dateien von Ansi auf UTF-8 gemacht, was sich wohl auch auf den Code und nicht nur auf den HTML  Bereich auswirkte. Warum, weiß ich noch nicht. Muss erstmal suchen.
Ich melde mich dann wieder.
Gruß
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 28 Januar 2017, 22:10:41
Hallo,

Hier nun etwas bereinigt. Habe beim saubermachen der Dateien ein \ gelöscht.

Würde mich über Feedback freuen.
Vor allem aber um die Dimmfunktion zu erweitern, oder die Definitionswerte zu trennen.

Gruß
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: memed am 29 Januar 2017, 00:16:10
Hi,
klappt jetzt wie erwartet :-)
Ich melde mich sobald ich was getestet habe.
Danke und Gruß
-M
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: memed am 18 Februar 2017, 17:29:00
Update:
Klappt soweit für die Schaltsteckdosen sehr gut, ich habe nur sehr, sehr selten einen Aussetzer -> sprich es wird nicht geschaltet.
Dimmer habe ich zwar hier liegen, nutze die aber nicht wirklich - da zu nur das Feedback, dass die automatisch gefunden und eingerichtet werden.
Ich habe manchmal den Effekt, dass Devices auftauchen, die nicht im Lernmodus waren.... das kann ich mir dann nicht richtig erklären.

Gruß M
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: Automation am 19 Februar 2017, 13:45:20
Hallo zusammen, versuche das REV Gateway mit "define TEST REVICOMFORT IPADRESS" einzufügen. Erhalte immer "Unknown module REVICOMFORT" Was mache ich falsch ? Grüße und schönen Sonntag Matthias
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 19 Februar 2017, 20:03:57
Hallo Automation,

sind beide Module im FHEM Verzeichnis, und tragen beide die Gruppe und den User, wie die anderen Module????
Danach Fhem restart. Dann muss es gehen. ;)

Hast du Linux oder Windows?? ::)
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: Automation am 20 Februar 2017, 16:16:36
Module im FHEM Verzeichnis ? Bin froh das es mit Max! und HUE und der Fritz Steckdose läuft, da brauchte ich nix in das FHEM Verzeichnis zu kopieren. Muss ich da etwas von WO? reinkopieren ? Gates hab ich verbannt. Hier läuft alles unter Linux und FreeBSD ;-) Grüße Matthias
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 22 Februar 2017, 14:23:15
Hallo,

Also die ganze Prozedur:

Die Dateien müssen in das */fhem/FHEM Verzeichnis mit den selben Benutzer und Root Rechten , wie die anderen Dateien.

mit ls -l */fhem/FHEM/*REVI*   Rechte überprüfen

mit chown fhem:dialout */fhem/FHEM/*REVI* rechte setzen

mit /etc/init.d/fhem stop fhem stoppen und

mit /etc/init.d/fhem start fhem starten. oder über die Fhem Weboberfläche mit shutdown restart.

Danach das Gateway anlegen mit "define REV_Gate REVICOMFORT IPAdresse"


Gruß

über die Fhem Weboberfläche.
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: stebar_ am 27 Februar 2017, 00:09:47
Hallo Zusammen,

wird das Modul auch offiziell in FHEM aufgenommen?
Ich bin am überlegen ob ich mir ein Set kaufe, da die Steckdosen nur halb so teuer wie die HM Geräte sind.

Viele Grüße
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 01 März 2017, 19:17:55
Hallo,

Das kann nur Rudolph entscheiden. Von meiner Seite steht dem nichts entgegen. Nur weiß ich nicht, ob das in dieser Versionsphase schon sinnvoll ist.
Ich denke, wenn dann sollte vielleicht noch ein wenig mehr Feedback von anderen Usern kommen.

Gruß
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: Pit@Jura am 20 März 2017, 00:28:18
Hallo elw,
funktioniert bei mir für REV Steckdosen mit Deiner Version vom 28. Januar und Deiner Anleitung perfekt!
Etwas verwirrend für mich war, dass Du verschiedene Stände der beiden *.pm Dateien hier im Forum verteilt hattest und diese nicht per Dateinamen unterscheidbar sind.
Ich habe außerdem noch Rolladensteuerungen von REV iComfort. Lohnt es sich schon diese auch zu testen?
Beste Grüße
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: giulup am 03 April 2017, 21:41:28
Super Arbeit! :)

Die Steckdosen funktionieren bei mir einwandfrei. Die Rolläden werden bei mir allerdings auch als Ein-/Aus- Schalter angelegt. Da die Schalter keine Rückmeldung über die aktuelle Position geben ist es unmöglich die nächste Fährt zu planen. Genauso verhält es sich wenn der Taster manuell gedrückt wird -> keine Meldung ans Gateway.

Anscheinend auch keine Möglichkeit seitens REV. Ist es möglich eine Lernfahrt zu programmieren? Damit sollten doch prozentuale Fahrten möglich sein?

Edit: Das Gateway ruft wohl in regelmäßigen Abständen die Rollladenschalter ab und erhält die letzte Fahrtrichtung nachdem der Rollladen von Hand bedient wurde.
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 17 April 2017, 20:37:54
Hallo,

Habe mittlerweile auch eine Markise, mit der ich die REV Module testen kann. Muss mir das Modul noch besorgen. Dann teste ich das aus und werde hier berichten ;).

Bis dann Gruß :)
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: rjans am 08 Mai 2017, 21:41:38
Hallo elw,
ich habe verzweifelt versucht, das REVICOMFORT- Modul zu finden.....
wo, bitte, kann ich mir das runterladen, danke.

Hintergrund:
ich möchte gerne das REVICOMFORT modul zu Steuerung meiner Stehlampen verwenden.
zudem möchte ich testen, ob die UP-Module eventuell einzubinden sind.
( da die zum ersten sehr billig sind und zum zweiten keinen Neutralleiter benötigen, was das ganze
etwas praxisgerechter macht). :-)


Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 09 Mai 2017, 08:16:49
Hallo rjans,

in meinem Beitrag vom 28.1.2017 findest Du beide Dateien zum runterladen. Lade beide Dateien runter.
In dem Beitrag vom 22. Februar steht, was Du damit machen musst.
Ansonsten melde Dich noch mal.

Gruß ;)
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: bommel-bs am 16 Mai 2017, 21:59:01
Hallo,

hat schon jemand Erfahrung mit iComfort Funk-Wandsender, Artikelnummer 0086320103 gemacht?
https://www.rev.de/DE_produkt_13210.ahtml (https://www.rev.de/DE_produkt_13210.ahtml)

Gruß
Stefan
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 15 Juni 2017, 18:34:23
Hallo,

Anbei die neue Version mit dem integrierten Jallousieaktor (84479). Habe aus Gründen der Flexibilität nicht alles in der Erstellung
des Devises festgeschrieben. Schaut auf die Bilder und ändert nach euren Wünschen die WebCmd, eventMap oder
DevStaeIcon.
SetExtension sind mit eingepflegt. Somit lassen sich auch zeitliche Fahrten programmieren.

Ich habe zeitweise den Fehler wie im Bild zu sehen. Ich weiß allerdings noch nicht genau, warum und wann er auftritt.
Bei den SetExtension blink und intervall ("set XXXXXXX blink 2 10" )trat er das erstes Mal beim 84462 auf, darum fehlen die auch in den Extensions. Wenn, dann wirds auch ins log geschrieben.
Ich vermute, das wenn Befehle in schneller Folge an den Aktor geschickt werden, dieser Fehler auftritt. Reboot Gateway ändert nichts, reboot Aktor auch nicht. Nur reboot Fhem hilft
Ich weiß nicht, ob man das irgendwo einstellen kann, das der String nur einmal geschickt wird. Vielleicht können die Profis da weiter helfen.


Die Taster oder Schalter von REV habe ich bisher nicht in der Hand gehabt. Da sie aber auch über das Gateway an die Aktoren senden, denke ich mal, übernimmt Fhem die Rückmeldung vom Aktor.

Gruß
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: Volker80 am 27 Juni 2017, 17:17:20
Hallo

bisher habe ich zwar nur gelesen und viel gelernt aber hierzu kann ich vielleicht etwas beitragen.

Ich habe selber 4 IComfort Rollo-Schalter in Benutzung. Das hat mit der App schon nicht wirklich gut geklappt aber mit FHEM könnte man es etwas verbessern.
Normalerweise erzeugt man diesen Fehler durch schnelles oder gleichzeitiges Schalten. Der STATE wird dann 255 und REV_Gate_RAWMSG ist F?a=********.

Nach ca 10-15 Schaltungen durch ein notify für die 4 Schalter mit jeweils 1Sekunde Pause  kommt nur noch der Fehler. Durch schalten jedes einzelnen Device wird der Fehler aufgehoben. Ich habe es versucht mit watchdog zu lösen, leider ohne Erfolg.
Bin aber noch weiter am probieren.
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: Volker80 am 12 Juli 2017, 11:25:47
So jetzt habe ich mal etwas Zeit gehabt und meine Rolladenschalter getestet.

Aktueller Logeintrag nach FHEM Neustart:

2017.07.12 10:50:04 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/79_REVI.pm line 109, <$fh> line 54.
2017.07.12 10:50:04 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/79_REVI.pm line 109, <$fh> line 93.

zudem zwischendurch ohne Aktionen:

2017.07.12 11:10:00 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/79_REVI.pm line 277.
2017.07.12 11:10:00 1: PERL WARNING: Use of uninitialized value $b[1] in concatenation (.) or string at ./FHEM/79_REVI.pm line 282.




Dann mal als Beispiel eine Aktion "on" (bei mir AUF)


LOGFILE:
2017.07.12 11:15:42 3: REVI (Kuechenfenster) - set Kuechenfenster on

und filelog des device:
2017-07-12_11:15:42 Kuechenfenster AUF
2017-07-12_11:15:42 Kuechenfenster AUF
2017-07-12_11:15:43 Kuechenfenster AUF
2017-07-12_11:18:47 Kuechenfenster AUF<----kommt von alleine

kommt der Befehl nun 1x oder 3x?

Hab es versucht mit nem notify zu beheben allerdings fehlt mir dazu etwas wissen.
Sobald der das device state 255 hat wird es nochmal auf on gesetzt(würde hier gerne den letzten Befehl wiederholen um beide Richtungen zu bedienen)
Bsp:
Logfile:
2017.07.12 11:10:17 3: REVI (Kuechenfenster) - set Kuechenfenster on
2017.07.12 11:10:17 3: REVI (REV_Gate) - Error backstate F addresse:001e8c31
2017.07.12 11:10:17 3: REVI (Kuechenfenster) - set Kuechenfenster on
2017.07.12 11:10:18 3: REVI (REV_Gate) - Error backstate F addresse:001e8c31
2017.07.12 11:10:18 3: REVI (Kuechenfenster) - set Kuechenfenster on
Filelog des device:
2017-07-12_11:10:17 Kuechenfenster AUF
2017-07-12_11:10:17 Kuechenfenster 255
2017-07-12_11:10:18 Kuechenfenster 255
2017-07-12_11:10:18 Kuechenfenster AUF
2017-07-12_11:10:19 Kuechenfenster AUF
2017-07-12_11:13:22 Kuechenfenster AUF <----kommt von alleine


Kann man die problem lösen?
Oder ist es ein Lösungsansatz mit notify zu arbeiten?
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 14 Juli 2017, 12:32:50
Hallo,

Die beiden Einträge nach Neustart und Zwischendurch tauchen bei mir nicht aus. Ich habe allerdings bislang die Devicelogs nicht benutzt.
werde mir das aber noch mal genauer ansehen, sie anlegen und testen.
Ich habe auch Fhem 5.8 drauf.

Genauso verhält sich das mit dem mehrmals senden der Befehle. Ich kann mir nur vostellen, dass es andere Devices sind REV. Ich habe bislang nur diese
SW 84462-B, Dim 84472-B, Jallousieaktor 84479-B mit Gateway 86500-B getestet. Falls Du andere hast, schick mir bitte die RAW Daten. Ich versuche dann diese einzupflegen.

Mit dem Backstate F kommt bei mir ebenfalls vor, wenn ich in schneller Folge Signale an das Gateway sende.
Ob das mit einem Delay hinzukriegen ist, das weiß, wann das letzte mal was gesendet wurde, weiß ich noch nicht.
Wie man das dann auch noch softwaretechnisch umsetzt, ??? ???.

Ich werde mir das mal anschauen.
Gruß
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: Thomas159 am 17 Juli 2017, 22:50:55
Hallo ELW,
kannst du mir bitte sagen wie du den Schlater 84489 hinzugefügt hast. Danke
Gruß
Thomas
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 18 Juli 2017, 11:25:48
Hey,
Kannst Du mir bitte sagen was "Schlater 84489" ist??????
Gruß
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: Thomas159 am 18 Juli 2017, 18:31:25
Sorry ich meinte natürlich 84479 Jalousieschalter. Sorry bin noch neu hier. Mit define test REVI 84479 hatte ich ihn schon hinzugefügt aber ich denke irgendwas fehlt noch. Hast du es eigentlich mit ein CUL getestet oder etwas anderem?
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 19 Juli 2017, 10:10:22
Hallo,

Der 84479 Jalousieschalter ist drinn und funktioniert bei mir. Hast du auch wirklich die letzte Version?
In der Device Hilfe unter Notes muss er drin stehen. Oder in der REVI Datei ganz oben

#20161121    remove Delete function
#20170124   dimmer integration, UTF-8 konversion,    help DE, EN
#20170610   jalousieaktor integration, setextensions eingepflegt

Gruß
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: Thomas159 am 19 Juli 2017, 17:16:35
Hallo,
ja ich habe die aktuelle Version genommen. Wenn ich die Datei richtig lese dann muss ich das mit eine Gateway machen oder?
Das habe ich aktuel nicht. Kannst du mir bitte sagen was ich dazu tun muss.
Gruß
Thomas
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 20 Juli 2017, 12:20:46
Hallo Thomas,

Ja, das ganze geht nur mit dem Gateway 86500-B. Dieses habe ich getestet.
Das gateway braucht eine feste IP. Am Besten über eien DHCP, da man nix einstellen kann am Gateway.
dann Define REV-Gate REVICOMFORT IP-Adresse. Das ist dann dein IO-DEV für die Steckdosen und Jallousie Devices.
Gruß
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: giulup am 21 Juli 2017, 14:09:21
Hallo Thomas,

Ich habe hier noch ein zusätzliches nicht benötigtes REV Gateway liegen. Falls du interessiert bist, lass es mich wissen.

Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: Thomas159 am 25 Juli 2017, 16:12:58
Hallo Guilup,
leider hab ich deine Nachricht erst zu spät gesehen und mir schon ein Gateway besorgt.
Ich kann das Rollo jetzt auch steuern. Nur leider stimmt der Staus nicht. Liefert der Schalter einen Status? Auch stimmt bei mir auf und zu nicht. War es bei euch auch so das ihr immer zwei mal schalten musstet damit etwas passiert?

Viele Grüße
Thomas
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 26 Juli 2017, 15:07:02
Hallo Thomas,
Denk bitte an das EventMap, wie in dem Bild von der Nachricht am 15.6.2017. Eventuell on:up off:down tauschen.

Gruß
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 26 Juli 2017, 16:15:35
Hallo,

Der 84479 gibt auch einen Status zurück. Wenn über der handy App gesteuert wird, sieht man die Reaktion in Fhem.

Gruß
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: Thomas159 am 27 Juli 2017, 12:26:41
Hallo,
danke für die Tipps aber auch tauschen oder etwas anderes hat leider nichts gebracht. Ich musste immer zwei "klicken" damit es überhaupt fährt und und der Status war damit immer falsch. Ich werde jetzt mal einen anderen Schalter (Homematic) versuchen.
Danke für deine Hilfe.
Gruß
Thomas
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: Volker80 am 13 Februar 2018, 09:11:22
Hallo zusammen

gibt es eigentlich neue Entwicklungen was die Zuverlässigkeit betrifft?

Meine Erfahrungen möchte ich natürlich auch gerne zur Verfügung stellen.

1. Dieser Fehler ist immernoch nach jeden FHEM start in der Logfile vorzufinden, bisher ohne erkennbare Einschränkungen
PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/79_REVI.pm line 109
das ist die Zeile 109
    Log3 $name, 5, "REVI ($name) - Define a0:".$a[0]." a1:".$a[1]." a2: ".$a[2]." a3: ".$a[3];   

2. zwischendurch kam es einmal vor, das ein JaluSchalter nicht mehr angesprochen wurde den dieser hatte auf einmal einen anderen Namen REVI_00000000
meine Fehlerbehebung verlief erfolglos aber durch umbennen de define in FHEM konnte ich es weiter nutzen. Nach einem Stromausfall hatte es seinen ursprünglichen Namen wieder.

3. Zuverlässigkeit: Naja man kann schon sagen das ca. 25% der Befehle nicht ausgeführt werden, was bei einer Zeitsteuerung schon lästig ist.
Meine Lösung: ich habe mir bei der Zeitsteuerung einfach eine Wiederholung nach 2 Minuten eingebaut.



gerne Kann ich die Logs zur Verfügung stellen

hurido bis denn
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 13 Februar 2018, 11:55:48
Hallo Zusammen,

Habe mich mal wieder dran gemacht und versucht euren Fehler nachzuvollziehen. Ja, unter einigen umständen tritt er bei mir auch auf.
Ich weiß allerdings im Moment nicht, wie ich ihn weg bekomme.

Den Fehler bekomme ich, wenn ich folgendes mache:

-automatisches anlegen der Devices unter REVICOMFORT
-umbenennen mit einem Namen
-Die Def ändern von  "001ea181 ?" in "001ea181 84479"
- Resultat zwei mal drücken um ein oder auszuschalten

Ich kann euch aber einen Workaraund anbieten:

- löscht diese Devices wieder und merkt euch die Adresse
- legt die Devices neu an mit "define Steckdose REVI 001ea181 84462"
- nun hatte ich bei jedem Druck eine Funktion.

Ich schau mal, ob ich den Fehler finde.

Gruß
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: Volker80 am 16 Februar 2018, 14:10:20
Hey

na vielleicht hilft dir das etwas. Ab Zeile 13 ist der Unterschied zu sehen.

Einmal mit Fehler

2018.02.13 09:06:22 5: REVI  (Terrasse_rechts)  def: (00195dc1 84479) String a: 2 b: 2 A0: Terrasse_rechts A1: on B0: 00195dc1 b1: 84479
2018.02.13 09:06:22 5: REVI  (Terrasse_rechts)  NEW REVI on
2018.02.13 09:06:22 5: REVI (Terrasse_rechts) funcset: 3F
2018.02.13 09:06:22 4: REVICOMFORT (REV_Gate) - sending data: S?d=3F&a=00195dc1
2018.02.13 09:06:22 5: (REV_Gate) REVICOMFORT  - S?d=3F&a=00195dc1
2018.02.13 09:06:22 5: (REV_Gate) REVICOMFORT  - send: S?d=3F&a=00195dc1
2018.02.13 09:06:22 5: (REV_Gate) REVICOMFORT  - send Hex: 533F643D334626613D3030313935646331
2018.02.13 09:06:22 5: SW: 533F643D334626613D30303139356463310A
2018.02.13 09:06:22 5: (REV_Gate) REVICOMFORT  - sending Data: 533F643D334626613D30303139356463310A
2018.02.13 09:06:22 5: REVI (Terrasse_rechts) send to IODEV: S?d=3F&a=00195dc1
2018.02.13 09:06:22 3: REVI (Terrasse_rechts) - set Terrasse_rechts on
2018.02.13 09:06:22 5: REVI  (Terrasse_rechts)  def: (00195dc1 84479) String a: 2 b: 2 A0: Terrasse_rechts A1: ? B0: 00195dc1 b1: 84479
2018.02.13 09:06:22 5: REVI  (Terrasse_rechts)  NEW REVI ?
2018.02.13 09:06:23 4: REVICOMFORT (REV_Gate) - received data: F?a=00195DC1

2018.02.13 09:06:23 5: REVICOMFORT (REV_Gate) - current buffer content: F?a=00195DC1

2018.02.13 09:06:23 4: REV_Gate  Parse send Data to REVI: REV_Gate  F?a=00195DC1
2018.02.13 09:06:23 5: REV_Gate: dispatch F?a=00195DC1
2018.02.13 09:06:23 5: REVI  (REV_Gate) Parse Message1: F?a=00195DC1
2018.02.13 09:06:23 5: REVI (REV_Gate) - Rückstate b: F 00195DC1 und splitt: F?a=00195DC1
2018.02.13 09:06:23 3: REVI (REV_Gate) - Error backstate F addresse:00195dc1
2018.02.13 09:06:23 5: REVI (REV_Gate) - Parse F 00195dc1 ? FF
2018.02.13 09:06:23 5: REVI  (REV_Gate)  - is defined F?a=00195DC1 hash: HASH(0x15703f8)
2018.02.13 09:06:23 5: REVI (REV_Gate) - def HASH(0x15703f8)
2018.02.13 09:06:23 5: REVI (REV_Gate) - lh HASH(0x15c0dc0)
2018.02.13 09:06:23 5: REVI (REV_Gate) - c 00195dc1 adresse 00195dc1
2018.02.13 09:06:23 5: REVI(REV_Gate) 1Integer list:  n: Terrasse_rechts
2018.02.13 09:06:23 5: REVI(REV_Gate) 2Integer list: 1
2018.02.13 09:06:23 5: REVI(REV_Gate) 2Integer n: Terrasse_rechts
2018.02.13 09:06:23 5: REVI(REV_Gate) Hex FunktionState: 255
2018.02.13 09:06:23 5: REVI (REV_Gate) - def HASH(0x16081c8)
2018.02.13 09:06:23 5: REVI (REV_Gate) - lh HASH(0x1607e68)
2018.02.13 09:06:23 5: REVI (REV_Gate) - c 0019f1f1 adresse 00195dc1
2018.02.13 09:06:23 5: REVI (REV_Gate) - def HASH(0x15d0298)
2018.02.13 09:06:23 5: REVI (REV_Gate) - lh HASH(0x15cf648)
2018.02.13 09:06:23 5: REVI (REV_Gate) - c 00195e01 adresse 00195dc1
2018.02.13 09:06:23 5: REVI (REV_Gate) - def HASH(0x156f8e0)
2018.02.13 09:06:23 5: REVI (REV_Gate) - lh HASH(0x1537be8)
2018.02.13 09:06:23 5: REVI (REV_Gate) - c  adresse 00195dc1
2018.02.13 09:06:23 5: REVI (REV_Gate) - def HASH(0x15d0d90)
2018.02.13 09:06:23 5: REVI (REV_Gate) - lh HASH(0x15d0a48)
2018.02.13 09:06:23 5: REVI (REV_Gate) - c 001e8c31 adresse 00195dc1
2018.02.13 09:06:23 5: REVI (REV_Gate) - def HASH(0x161a638)
2018.02.13 09:06:23 5: REVI (REV_Gate) - lh HASH(0x1618c90)
2018.02.13 09:06:23 5: REVI (REV_Gate) - c 001b48d1 adresse 00195dc1
2018.02.13 09:06:23 5: REVI  (REV_Gate)  - F?a=00195DC1 is defined for List Terrasse_rechts
2018.02.13 09:06:23 5: REVI  (Terrasse_rechts)  def: (00195dc1 84479) String a: 2 b: 2 A0: Terrasse_rechts A1: ? B0: 00195dc1 b1: 84479
2018.02.13 09:06:23 5: REVI  (Terrasse_rechts)  NEW REVI ?


Einmal ohne Fehler

2018.02.13 09:06:23 5: REVI  (Terrasse_links)  def: (0019F1F1 84479) String a: 2 b: 2 A0: Terrasse_links A1: on B0: 0019F1F1 b1: 84479
2018.02.13 09:06:23 5: REVI  (Terrasse_links)  NEW REVI on
2018.02.13 09:06:23 5: REVI (Terrasse_links) funcset: 3F
2018.02.13 09:06:23 4: REVICOMFORT (REV_Gate) - sending data: S?d=3F&a=0019F1F1
2018.02.13 09:06:23 5: (REV_Gate) REVICOMFORT  - S?d=3F&a=0019F1F1
2018.02.13 09:06:23 5: (REV_Gate) REVICOMFORT  - send: S?d=3F&a=0019F1F1
2018.02.13 09:06:23 5: (REV_Gate) REVICOMFORT  - send Hex: 533F643D334626613D3030313946314631
2018.02.13 09:06:23 5: SW: 533F643D334626613D30303139463146310A
2018.02.13 09:06:23 5: (REV_Gate) REVICOMFORT  - sending Data: 533F643D334626613D30303139463146310A
2018.02.13 09:06:23 5: REVI (Terrasse_links) send to IODEV: S?d=3F&a=0019F1F1
2018.02.13 09:06:23 3: REVI (Terrasse_links) - set Terrasse_links on
2018.02.13 09:06:23 5: REVI  (Terrasse_links)  def: (0019F1F1 84479) String a: 2 b: 2 A0: Terrasse_links A1: ? B0: 0019F1F1 b1: 84479
2018.02.13 09:06:23 5: REVI  (Terrasse_links)  NEW REVI ?
2018.02.13 09:06:23 4: REVICOMFORT (REV_Gate) - received data: G?a=0019F1F1&d=3F

2018.02.13 09:06:23 5: REVICOMFORT (REV_Gate) - current buffer content: G?a=0019F1F1&d=3F

2018.02.13 09:06:23 4: REV_Gate  Parse send Data to REVI: REV_Gate  G?a=0019F1F1&d=3F
2018.02.13 09:06:23 5: REV_Gate: dispatch G?a=0019F1F1&d=3F
2018.02.13 09:06:23 5: REVI  (REV_Gate) Parse Message1: G?a=0019F1F1&d=3F
2018.02.13 09:06:23 5: REVI (REV_Gate) - Rückstate b: G 0019F1F1 &d=3F und splitt:  G 0019F1F1 d 3F
2018.02.13 09:06:23 5: REVI (REV_Gate) - Rückstate E oder G : G 0019f1f1 d 3F
2018.02.13 09:06:23 5: REVI (REV_Gate) - Parse G 0019f1f1 d 3F
2018.02.13 09:06:23 5: REVI  (REV_Gate)  - is defined G?a=0019F1F1&d=3F hash: HASH(0x16081c8)
2018.02.13 09:06:23 5: REVI (REV_Gate) - def HASH(0x15703f8)
2018.02.13 09:06:23 5: REVI (REV_Gate) - lh HASH(0x15c0dc0)
2018.02.13 09:06:23 5: REVI (REV_Gate) - c 00195dc1 adresse 0019f1f1
2018.02.13 09:06:23 5: REVI (REV_Gate) - def HASH(0x16081c8)
2018.02.13 09:06:23 5: REVI (REV_Gate) - lh HASH(0x1607e68)
2018.02.13 09:06:23 5: REVI (REV_Gate) - c 0019f1f1 adresse 0019f1f1
2018.02.13 09:06:23 5: REVI(REV_Gate) 1Integer list:  n: Terrasse_links
2018.02.13 09:06:23 5: REVI(REV_Gate) 2Integer list: 1
2018.02.13 09:06:23 5: REVI(REV_Gate) 2Integer n: Terrasse_links
2018.02.13 09:06:23 5: REVI (REV_Gate) - def HASH(0x15d0298)
2018.02.13 09:06:23 5: REVI (REV_Gate) - lh HASH(0x15cf648)
2018.02.13 09:06:23 5: REVI (REV_Gate) - c 00195e01 adresse 0019f1f1
2018.02.13 09:06:23 5: REVI (REV_Gate) - def HASH(0x156f8e0)
2018.02.13 09:06:23 5: REVI (REV_Gate) - lh HASH(0x1537be8)
2018.02.13 09:06:23 5: REVI (REV_Gate) - c  adresse 0019f1f1
2018.02.13 09:06:23 5: REVI (REV_Gate) - def HASH(0x15d0d90)
2018.02.13 09:06:23 5: REVI (REV_Gate) - lh HASH(0x15d0a48)
2018.02.13 09:06:23 5: REVI (REV_Gate) - c 001e8c31 adresse 0019f1f1
2018.02.13 09:06:23 5: REVI (REV_Gate) - def HASH(0x161a638)
2018.02.13 09:06:23 5: REVI (REV_Gate) - lh HASH(0x1618c90)
2018.02.13 09:06:23 5: REVI (REV_Gate) - c 001b48d1 adresse 0019f1f1
2018.02.13 09:06:23 5: REVI  (REV_Gate)  - G?a=0019F1F1&d=3F is defined for List Terrasse_links
2018.02.13 09:06:23 5: REVI  (Terrasse_links)  def: (0019F1F1 84479) String a: 2 b: 2 A0: Terrasse_links A1: ? B0: 0019F1F1 b1: 84479
2018.02.13 09:06:23 5: REVI  (Terrasse_links)  NEW REVI ?
2018.02.13 09:06:24 4: REVICOMFORT (REV_Gate) - received data: G?a=0019F1F1&d=3F

2018.02.13 09:06:24 5: REVICOMFORT (REV_Gate) - current buffer content: G?a=0019F1F1&d=3F

2018.02.13 09:06:24 4: REV_Gate  Parse send Data to REVI: REV_Gate  G?a=0019F1F1&d=3F
2018.02.13 09:06:24 5: REV_Gate: dispatch G?a=0019F1F1&d=3F
2018.02.13 09:06:24 5: REVI  (REV_Gate) Parse Message1: G?a=0019F1F1&d=3F
2018.02.13 09:06:24 5: REVI (REV_Gate) - Rückstate b: G 0019F1F1 &d=3F und splitt:  G 0019F1F1 d 3F
2018.02.13 09:06:24 5: REVI (REV_Gate) - Rückstate E oder G : G 0019f1f1 d 3F
2018.02.13 09:06:24 5: REVI (REV_Gate) - Parse G 0019f1f1 d 3F
2018.02.13 09:06:24 5: REVI  (REV_Gate)  - is defined G?a=0019F1F1&d=3F hash: HASH(0x16081c8)
2018.02.13 09:06:24 5: REVI (REV_Gate) - def HASH(0x15703f8)
2018.02.13 09:06:24 5: REVI (REV_Gate) - lh HASH(0x15c0dc0)
2018.02.13 09:06:24 5: REVI (REV_Gate) - c 00195dc1 adresse 0019f1f1
2018.02.13 09:06:24 5: REVI (REV_Gate) - def HASH(0x16081c8)
2018.02.13 09:06:24 5: REVI (REV_Gate) - lh HASH(0x1607e68)
2018.02.13 09:06:24 5: REVI (REV_Gate) - c 0019f1f1 adresse 0019f1f1
2018.02.13 09:06:24 5: REVI(REV_Gate) 1Integer list:  n: Terrasse_links
2018.02.13 09:06:24 5: REVI(REV_Gate) 2Integer list: 1
2018.02.13 09:06:24 5: REVI(REV_Gate) 2Integer n: Terrasse_links
2018.02.13 09:06:24 5: REVI (REV_Gate) - def HASH(0x15d0298)
2018.02.13 09:06:24 5: REVI (REV_Gate) - lh HASH(0x15cf648)
2018.02.13 09:06:24 5: REVI (REV_Gate) - c 00195e01 adresse 0019f1f1
2018.02.13 09:06:24 5: REVI (REV_Gate) - def HASH(0x156f8e0)
2018.02.13 09:06:24 5: REVI (REV_Gate) - lh HASH(0x1537be8)
2018.02.13 09:06:24 5: REVI (REV_Gate) - c  adresse 0019f1f1
2018.02.13 09:06:24 5: REVI (REV_Gate) - def HASH(0x15d0d90)
2018.02.13 09:06:24 5: REVI (REV_Gate) - lh HASH(0x15d0a48)
2018.02.13 09:06:24 5: REVI (REV_Gate) - c 001e8c31 adresse 0019f1f1
2018.02.13 09:06:24 5: REVI (REV_Gate) - def HASH(0x161a638)
2018.02.13 09:06:24 5: REVI (REV_Gate) - lh HASH(0x1618c90)
2018.02.13 09:06:24 5: REVI (REV_Gate) - c 001b48d1 adresse 0019f1f1
2018.02.13 09:06:24 5: REVI  (REV_Gate)  - G?a=0019F1F1&d=3F is defined for List Terrasse_links
2018.02.13 09:06:24 5: REVI  (Terrasse_links)  def: (0019F1F1 84479) String a: 2 b: 2 A0: Terrasse_links A1: ? B0: 0019F1F1 b1: 84479
2018.02.13 09:06:24 5: REVI  (Terrasse_links)  NEW REVI ?

Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: Volker80 am 20 Februar 2018, 04:53:52
Zitat von: elw am 13 Februar 2018, 11:55:48
Ich kann euch aber einen Workaraund anbieten:

- löscht diese Devices wieder und merkt euch die Adresse
- legt die Devices neu an mit "define Steckdose REVI 001ea181 84462"
- nun hatte ich bei jedem Druck eine Funktion.

Hey,
das bringt leider keine Veränderung. Aber trotzdem Danke
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 21 Februar 2018, 14:13:32
Hallo Volker80,
bin gerade dabei das ganze zu recherieren. Dabei ist mir im Workaround ein Fehler passeirt.

Es sollte eher so heißen:

- löscht die Devices wieder und merkt euch die Adressen

- Bitte Fhem neu starten (shutdown restart) oder /etc/init.d/fhem restart

- legt die Devices neu an mit "define Steckdose REVI 001ea181 84462"
- nun hatte ich bei jedem Druck eine Funktion.


Das Problem liegt beim Rename and Delete. Warum weiß ich noch nicht. Viele Module besitzen diese Funktionen nicht und es geht trotzdem. Vielleicht mache ich schon beim Autocreate einen Fehler. Ich schaue noch mal weiter und stelle dann die Version ein, mit der ich gerade teste.

Gruß
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 21 Februar 2018, 15:17:06
Hallo,

Ich habe mal eine frage an die Experten. So wie ich das sehe existiert nach dem umbenennen oder dem Löschen des Devices dieses noch irgendwo.

2018.02.21 14:42:22 5: REVI (REVI_Gate) - Parse G 00037a91 d 3F
2018.02.21 14:42:22 5: REVI  (REVI_Gate)  - is defined G?a=00037A91&d=3F hash: HASH(0x10d8690)
2018.02.21 14:42:22 5: REVI (REVI_Gate) - def HASH(0x10d8c18)
2018.02.21 14:42:22 5: REVI (REVI_Gate) - lh HASH(0x10d87c8)
2018.02.21 14:42:22 5: REVI (REVI_Gate) - c 00217c31 adresse 00037a91
2018.02.21 14:42:22 5: REVI (REVI_Gate) - def HASH(0x10b3fe0)
2018.02.21 14:42:22 5: REVI (REVI_Gate) - lh HASH(0xcebd98)
2018.02.21 14:42:22 5: REVI (REVI_Gate) - c 0021c2c1 adresse 00037a91
2018.02.21 14:42:22 5: REVI (REVI_Gate) - def HASH(0x10d8690)
2018.02.21 14:42:22 5: REVI (REVI_Gate) - lh HASH(0x10b3ff8)
2018.02.21 14:42:22 5: REVI (REVI_Gate) - c 00037a91 adresse 00037a91
2018.02.21 14:42:22 5: REVI(REVI_Gate) 1Integer list:  n: REVI_00037a91
2018.02.21 14:42:22 5: REVI(REVI_Gate) 2Integer list: 1
2018.02.21 14:42:22 5: REVI(REVI_Gate) 2Integer n: REVI_00037a91
2018.02.21 14:42:22 5: REVI (REVI_Gate) - lh HASH(0x10b3ff8)
2018.02.21 14:42:22 5: REVI (REVI_Gate) - c 00037a91 adresse 00037a91
2018.02.21 14:42:22 5: REVI(REVI_Gate) 1Integer list: REVI_00037a91 n: Schreibtisch_Dimmer_91
2018.02.21 14:42:22 5: REVI(REVI_Gate) 2Integer list: 2
2018.02.21 14:42:22 5: REVI(REVI_Gate) 2Integer n: Schreibtisch_Dimmer_91
2018.02.21 14:42:22 5: REVI (REVI_Gate) - def HASH(0x10d89a8)
2018.02.21 14:42:22 5: REVI (REVI_Gate) - lh HASH(0x10ed580)
2018.02.21 14:42:22 5: REVI (REVI_Gate) - c 001ea181 adresse 00037a91
2018.02.21 14:42:22 5:[i] REVI  (REVI_Gate)  - G?a=00037A91&d=3F is defined for List REVI_00037a91 Schreibtisch_Dimmer_91[/i]
2018.02.21 14:42:22 1: ERROR: >REVI_00037a91< returned by the REVI ParseFn is invalid, notify the module maintainer


In der vorletzten Zeile sieht man, das REVI_00037a91 und das Schreibtisch_Dimmer_91 Device noch vorhanden ist.
Diese dürfte dann auch der fehler sein, ds das Device nicht sauber gelöscht wird. Kann mir da bitte jemand weiterhelfen?

DANKE

Gruß
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 21 Februar 2018, 15:40:14
Hallo,
Ich möchte noch mal zusammenfassen:

- ein Löschen des Devices löscht es nicht komplett, sondern nur in der fhem.cfg.
       - ich dachte eigentlich, dass das Löschen global übernommen wird und nur lt Develoment spezielle Dateien und 
          Attribute gelöscht werden müssen.
- ein Umbenennen mit meiner RenameFn benennt das Device und z.b. Filelogs mit um, löscht aber nicht das alte Device

Vielleicht gibt es da ja jemanden, der einen Tip hat.

Gruß
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 02 März 2018, 14:05:09

Hallo,

Habe das Modul REVI komplett überarbeitet. Ein Löschen und Umbenennen ist nun auch ohne Fhem Neustart möglich.
Einen großen Dank an Markus Bloch, der mich auf den richtigen Weg gebracht hat.

Wenn der Fehler mit dem Gateway auftaucht könnt Ihr auf den state "255" reagieren und gegebenenfalls das Signal wiederholen.
Last es mich wissen, wenn es irgendwo hakt, oder Ihr noch Wünsche habt.

Gruß
ELW
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: Volker80 am 03 März 2018, 17:07:48
Sehr gut. Ich werde die Funktionen für 84479 intensiv testen und berichten.

Da hab ich gleich ne Kleinigkeit für 84479 Rolloschalter

Der set-Befehl stop kann raus da ohne Funktion.

ZitatWenn der Fehler mit dem Gateway auftaucht könnt Ihr auf den state "255" reagieren und gegebenenfalls das Signal wiederholen.
Last es mich wissen, wenn es irgendwo hakt, oder Ihr noch Wünsche habt.
Wie kann das umgesetzt werden?
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: Funatic am 22 April 2018, 13:59:49
Hallo ELW,

ich nutze iComfort dank Deines Codes in Kombination mit Rollo und Clunis Rolladensteuerung.

Auch ich habe oft Probleme, dass Steuerbefehle nicht am iComfort Aktor ankommen. Das ist ziemlich ärgerlich, wenn die einzelne Rollläden im Urlaub tagsüber unten oder nachts oben bleiben. Passiert zum Glück nicht ganz so häufig, da das zweite Kommando, das den Motor dann nach z.B. 30s ausschalten sollte dann als start-Befehl interpretiert wird und der Rollladen dann zum Glück doch noch schließt oder öffnet (kommt trotzdem noch zu häufig vor, dass er eben doch unbewegt bleibt).
Richtig doof wird das ganze aber, wenn ein Rollladen nicht zu 100% geschlossen oder geöffnet wereden soll. Z.B. beim Sonnenschutz, beim Lüften oder beim entspannteren Aufwachen, bei dem der Rollladen erstmal nur ein klein wenig geöffnet werden soll. Ein verpasstes Signal macht dann die ganze Programmierung hinfällig...
Mir wäre als auch sehr daran gelegen, wenn Du die Zuverlässigkeit erhöhen könntest.

Was hälst Du von folgender Idee:
- nach dem Senden eines Kommandos (z.B. Jalousieschalter hoch) fragst du unmittelbar den Status des Aktors ab. Der sollte ja nun auf "hoch" (on) stehen.
- Ist der Status nicht wie erwartet, sendest Du das Kommando nocheinmal.
- Das ganze 3x dann gibst du auf und belässt es dabei. Unbedingt eine ungerade Anzahl an Wiederholungen versuchen - sollte das Kommando nämlich wider erwarten doch durchgegangen sein, dann wird bei jeder geraden Wiederholung das Kommando gestoppt, bei der ungeraden wieder getriggert...

Bin gespannt auf dein (oder auch fremdes) Feedback!


Gruß,

Thomas
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 30 April 2018, 12:38:59
Hallo Funatic,

Schade, das du solche Probleme damit hast. :-\
Da ich das ganze erst nochmal überprüft habe, jetzt erst die Antwort.

Bei mir sind 2x 24iger Wände zwischen Gateway und Aktor. das ganze geht über 868 MHZ und das sollte eigentlich nicht so kritisch sein und funktionieren.
Hast Du mal versucht die Entfernung zwischen beiden zu verringern? Geh doch mal mit Putty über Telnet auf dein Gateway und gib die Befehle ein.
Damit kannst du Fhem ausschließen.

Die Rückmeldung kommt automatisch vom Gateway ohne Pollen. Somit ist es schwierig ein Timeout hinzubekommen.
Dein Vorschlag würde bedeuten, einen Interrupt nach Befehlseingabe starten, warten auf Antwort, wenn keine kommt noch mal senden.....usw......
Abgesehen davon, das ich nicht weiß wie man so was programmiert, dürfte das sehr aufwendig sein, aber bestimmt machbar.

Kannst Du mir noch sagen, was Clunis Rolladensteuerungen sind???
Hast Du das Gateway  86500-B oder ein anderes??

Gruß
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: elw am 30 April 2018, 13:28:17
Hallo,

Hier noch die Befehle für Putty   ;) "S?d=3F&a=ADRESSE" oder "S?d=00&a=ADRESSE". In Putty dann CTRL+J danach Enter.

Gruß
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: Funatic am 01 Mai 2018, 18:59:24
Hi ELW,

ich habe eben versucht auf das Gateway (ja, 86500-B) zu kommen. Network Timeout. Weder per ssh noch per telnet. Irritiert mich etwas, dass du sagst, das müsste funktionieren. Werde es später nochmal über LAN probieren - erwarte aber keine Änderung, ist das selbe Netzwerksegment...

Prinzipiell funktioniert das Gateway ja auch. Ich schicke den Befehl ab und im FHEM Event Monitor sehe ich den Befehl dann 3x:

2018-05-01 18:50:04 REVI Motor.Rollladen.Kinderzimmer.Nord down
2018-05-01 18:50:05 REVI Motor.Rollladen.Kinderzimmer.Nord down
2018-05-01 18:50:05 REVI Motor.Rollladen.Kinderzimmer.Nord down

Ich vermute das erste ist mein Trigger, das zweite die Response vom Gateway und das dritte die Response vom Aktor.

Nach 3 Minuten sehe ich dann nochmals ein einzelnes Event - vermute das ist das Abschalt-Event vom Aktor, wenn von der Steuerung kein Stop gesendet wurde.

2018-05-01 18:53:08 REVI Motor.Rollladen.Kinderzimmer.Nord down

Ich kann den Fehler im Moment gerade nicht reproduzieren - aber im Log sehe ich z.B. auch folgendes:

2018-05-01_18:35:27 Motor.Rollladen.Kinderzimmer.Nord down
2018-05-01_18:35:27 Motor.Rollladen.Kinderzimmer.Nord down
2018-05-01_18:35:27 Motor.Rollladen.Kinderzimmer.Nord down
2018-05-01_18:35:27 Motor.Rollladen.Kinderzimmer.Nord 255
2018-05-01_18:35:28 Motor.Rollladen.Kinderzimmer.Nord down

Bin mir jetzt aber nicht sicher, ob er sich bewegt hat oder nicht...

Es ist auch (nicht nur) der Entfernung geschuldet. O.g. Rollladen ist im selben Zimmer wie das Gateway, ca. 2m Luftlinie...


Ich habe die Rollladen-Aktoren über das Rollo-Modul eingebunden. Als Zeitsteuerung nutze ich die Rollladensteuerung von Cluni (https://forum.fhem.de/index.php/topic,73964.0.html), die mit dem Rollo-Modul umgehen kann.
Prinzipiell geht auch alles - nur eben nicht 100%ig zuverlässig...

Was brauchst Du denn für Informationen, um das Verhalten zu analysieren und ggfs. eine Verbesserung schaffen zu können? Ich will ja gerne liefern, muss nur wissen was... ;-)


Vielen Danke für Deine Unterstützung!


Gruß,

Thomas
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: Funatic am 01 Mai 2018, 20:42:05
Nochmal ein Update.
Habe soeben einen Rollladen nach oben fahren lassen wollen. Er war  - warum auch immer - nicht ganz oben, sondern ca. 1/3 geschlossen. Obwohl das Rollo-Modul offen angezeigt hat.

Ich habe auf "open" geklickt - und er ist NICHT gefahren. Dafür dann ein paar Sekunden später.

Folgendes sehe ich im Event Monitor:

2018-05-01 20:22:51 readingsGroup Rollladen_Timer Rollladen.Bad.Sued.pct: 100
2018-05-01 20:22:51 ROLLO Rollladen.Bad.Sued command: open
2018-05-01 20:22:51 ROLLO Rollladen.Bad.Sued desired_position: 0
2018-05-01 20:22:51 ROLLO Rollladen.Bad.Sued pct: 100
2018-05-01 20:22:51 readingsGroup Rollladen_Timer Rollladen.Bad.Sued.pct: 100
2018-05-01 20:22:51 ROLLO Rollladen.Bad.Sued last_drive: drive-up
2018-05-01 20:22:51 ROLLO Rollladen.Bad.Sued drive-up
2018-05-01 20:22:51 ROLLO Rollladen.Bad.Sued pct: 100
2018-05-01 20:22:51 readingsGroup Rollladen_Timer Rollladen.Bad.Sued.pct: 100
2018-05-01 20:22:51 ROLLO Rollladen.Bad.Sued drive-type: modul
2018-05-01 20:22:51 ROLLO Rollladen.Bad.Sued pct: 100
2018-05-01 20:22:51 REVI Motor.Rollladen.Bad.Sued up
2018-05-01 20:22:51 REVI Motor.Rollladen.Bad.Sued 255
2018-05-01 20:22:55 REVI Motor.Rollladen.Bad.Sued up
2018-05-01 20:22:55 readingsGroup Rollladen_Timer Rollladen.Bad.Sued.pct: 100
2018-05-01 20:22:55 dummy Rollladensteuerung letzter_Zugriff_Automatik_Komfort: 20:22:55
2018-05-01 20:22:55 ROLLO Rollladen.Bad.Sued open
2018-05-01 20:22:55 ROLLO Rollladen.Bad.Sued pct: 100
2018-05-01 20:22:55 REVI Motor.Rollladen.Bad.Sued up
2018-05-01 20:22:55 REVI Motor.Rollladen.Bad.Sued up
2018-05-01 20:24:26 LaCrosse Sensor.Temperatur.Schlafzimmer temperature: 22.5
2018-05-01 20:25:57 REVI Motor.Rollladen.Bad.Sued up

Um 20:22:51 wird das "Up" Kommando gesendet, das vom Gateway aber mit ReturnCode 255 quittiert wird. Der Rollladen fährt NICHT.
Da das Rollo-Modul davon ausging, dass der Rollladen bereits oben ist, hat es nach 20:22:55 das Stop-Kommando (also ein erneutes Up) geschickt. Dieses wurde richtig gesendet und der Rollladen ging hoch. Zeitverzögert eben.

Das ist jetzt kein Problem - er ist ja oben, da wo er hin sollte.
Wenn ich den Rollladen aber auf 50% fahren lassen will, dann darf kein Signal verloren gehen - denn dann landet er - wie in diesem Beispiel - oben (statt z.B. geplant 4s später wieder gestoppt...)

Im Filelog des REVI Aktors sieht das so aus:

2018-05-01_20:22:51 Motor.Rollladen.Bad.Sued up
2018-05-01_20:22:51 Motor.Rollladen.Bad.Sued 255
2018-05-01_20:22:55 Motor.Rollladen.Bad.Sued up
2018-05-01_20:22:55 Motor.Rollladen.Bad.Sued up
2018-05-01_20:22:55 Motor.Rollladen.Bad.Sued up
2018-05-01_20:25:57 Motor.Rollladen.Bad.Sued up

Die ersten 2, die nicht funktioniert haben, das funktionierende Stop-Kommando (das dann als up fungiert hat) und 3 Minuten später das Auto-Stop (das gar nicht hätte kommen dürfen, da das Rollo-Modul die Fahrt ja eigentlich gestoppt hatte...)

Gruß,

Thomas
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: Naked Snake am 27 August 2022, 14:18:27
Hallo Zusammen,

ich habe mir auch Funksteckdosen vom Typ 86500-B besorgt und versuche Sie gerade in Fhem einzufügen. Blicke momentan auch noch nicht in Fhem ganz durch, aber der Beitrag von Siddyfly war schon mega, nur weiß ich aktuell nicht wie und auf welchem Weg ich die IP-Adresse meiner Funksteckdosen ermittle. Wie habt ihr das gemacht?

Gruß


"
(Zitat von Siddyfly)
hier das kleine script mit dem man alle geräte auslesen kann.
Ich hoffe das geht bei euch, ich hab einen Raspi am laufen.
Somit bleibt das große krabbeln und das Öffnen der Unterputzdosen aus. Ihr müsst nur die IP Adresse im Script anpassen.


In die fhem.cfg hab ich es so eingebaut.

#REV ICOMFORT definition LampeKueche 00011511
define REVI_00011511 REVI 00011511
attr REVI_00011511 IODev ICOMFORT
attr REVI_00011511 alias LampeKueche
attr REVI_00011511 devStateIcon on:black_FS20.on:off off:black_FS20.off:on
attr REVI_00011511 room Wohnzimmer
define FileLog_REVI_00011511 FileLog ./log/REVI_00011511-%Y.log REVI_00011511
attr FileLog_REVI_00011511 logtype text
attr FileLog_REVI_00011511 room logfiles
"
Titel: Antw:Neues Modul für REV Ritter iComfort
Beitrag von: Naked Snake am 31 August 2022, 10:43:09
Muss ich für define Steckdose REVI 001ea181 84462 ein zusätzliches Modul installieren, denn jedesmal bekomme ich die Meldung "Unknown Modul REVI"
Titel: Aw: Neues Modul für REV Ritter iComfort
Beitrag von: schrmh am 20 März 2023, 23:11:58
Hat jemand noch den Inhalt von /icomfort/update/version.txt?
Es sieht so aus, als ob die Android-App eine Verbindung zu 62.159.226.202 aufbaut und dort nach dieser Datei sucht, sie aber nicht findet.