Hallo zusammen,
nachdem mein originaler Ankündigungsthread im CUL-Entwicklerforum (http://forum.fhem.de/index.php/topic,24158.html (http://forum.fhem.de/index.php/topic,24158.html) ) schon sehr off-topic geworden ist,
eröffne ich hier einen neuen Thread, um die Weiterentwicklung des FHEM-Moduls für Somfy RTS zu koordinieren.
Mein Code dafür liegt auf github: https://github.com/thdankert/somfy-rts-fhem (https://github.com/thdankert/somfy-rts-fhem).
Grüße,
Thomas
Hallo Elektrolurch,
danke für die Nachricht, und dein Angebot, mitzuentwickeln!
Zitat von: Elektrolurch am 12 Juli 2014, 19:55:22
Hallo Thomas,
CUL 433 ist angekommen und die 9 Somfys sind angelernt. Funktioniert alles. Leider kann man aber wohl über setList kein Menü den Somfys direkt zuordnen. Da musste ich noch einen dummy zwischen schalten.
Hmm, da habe ich vielleicht noch einen Fehler im Modul... braucht man für setList noch irgendetwas, oder sollte das "einfach so" funktionieren?
Zitat
Ich würde gerne das Somfy-Modul erweitern und wollte das mit Dir abstimmen, damit die Versionen nicht auseinander laufen.
1. Ich würde gerne ein Attribut "slaves" einführen. Das hat folgenden Hintergrund: Ich habe die Somfys jeweils einzeln und alle auf einen gemeinsamen Kanal "Alle_Rolladen" angelernt. Jetzt wäre es aus meiner Sicht sinnvoll, wenn ich bei "Alle_Rolladen" "slaves" definiere und die Mitglieder des gemeinsamen Kanals bzgl. state und SATE korrekt setze. Derzeit mache ich das außerhalb des Moduls. Ich denke an eine zukünftige Erweiterung, bei der man dann auch über fhem mitbekommt, wenn eine Somfy FB einen Rolladen verfährt.. Dazu müsste man ja für die FB ein ein eigenes device anlegen und als "slaves" den Rolladen eintragen.
Lässt sich das Verhalten nicht schon in FHEM mit einer structure abbilden? Damit lassen sich doch ebenfalls Devices zusammenfassen und gemeinsam steuern.
Ich würde das ungern nachbauen.
Um die Signale einer originalen FB korrekt zuzuordnen, würde es schon reichen, einem Device noch Sub-Adressen zuordnen zu können.
Dann müsste das Modul beim Empfang eines original-FB-Befehls nur noch schauen, zu welchem Gerät die Adresse gehört, und den Status korrekt aktualisieren.
Aus meiner Sicht ist es nicht so sinnvoll, ein neues Device für die original-FBs anzulegen - da ist die Gefahr zu groß,
dass man es normal in FHEM benutzt, und dadurch die original FB nicht mehr funktionert (weil der Rolling-Code nicht mehr stimmt).
Zitat
2. Ich würde mir mal ansehen, wie man eine eigene Ausgabe für das Modul Somfy hinbekommt. Dabei würde ich setList und eventMap auswerten, z.B. so:
devStateIcon geschlossen:fts_shutter_100 gesperrt:fts_shutter_90 Sonnenschutz:fts_shutter_50 offen:fts_shutter_10
eventMap /on:geschlossen/off:offen/go-my:gesperrt/off-for-timer 5/Dämmerung/on-for-timer 7:Sonnenschutz/
group Rolladen
setList state:geschlossen,gesperrt,Dämmerung,Sonnenschutz,offen
webCmd state
Man bekäme dann ein Menü mit den Eintragungen: geschlossen,gesperrt,Dämmerung,Sonnenschutz,offen
wie ich es derzeit über einen dummy realisiere.
(Wahrscheinlich kann man einen Teil des Codes vom Modul dummy dazu verwenden, muss ich mir allerdings noch ansehen)
Ich vermute, dafür gibt es schon fertigen Code in FHEM, den ich nur noch nicht nutze, ähnlich wie die SetExtensions.
Das übersteigt aber mein bisheriges Wissen vom FHEM-Sourcecode.
Zitat
Später möchte ich gerne noch die Fahrzeiten der Rollos einbringen, so dass man auch z.B. über
set Roll1 Pos 73 eine Position anfahren kann.
Ich habe das schon für meine Markise und einem slider gebaut und funktioniert tatellos.
Das finde ich eine sehr gute Idee! Wollte ich schon selbst einbauen, bin nur noch nicht dazu gekommen...
Dann kann ich auch endlich mehr als nur die "go-my" Position anfahren.
Teile des Codes in on-/off-for-timer könnte man dafür wiederverwenden.
Zitat
Wir müssten uns nur abstimmen, damit nicht ev. Verionen auseinander laufen. Ich würde die Änderungen dann hier einstellen und Du könntest sie prüfen und dann einchecken.
Wg. Urlaub kann ich so ab Mitte August damit anfangen. Wäre das ok?
Zur Entwicklung schlage ich github vor - das eignet sich ideal, wenn mehrere Personen am gleichen Code arbeiten wollen.
Hier habe ich das bisherige Modul schon hochgeladen: https://github.com/thdankert/somfy-rts-fhem (https://github.com/thdankert/somfy-rts-fhem)
Nenn mir einfach deinen Nutzernamen dort, und ich gebe dir Lese+Schreibrechte für das Repository.
Grüße,
Thomas
Hallo Thomas,
den Account habe ich unter "Elektrolurch" angelegt. Mal sehen, ob ich mit der Seite zurecht komme, da ichh auf einen Screenreader angewiesen bin und da scheinen einige Links nur als Ikon vorhanden zu sein.
Mit den "sub - Adressen" wäre natürlich eleganter, da gebe ich Dir recht, aber das geht dann schon wieder tiefer in den Code hinein, den Du geschrieben hast.
Ich habe mir in letzter Zeit bei der readingsGroup die HTML-Erzeugung angesehen und ich denke, dasss man da einen Teil aus dem dummy-Modul verwenden könnte. Ich sehe mir mal das in den nächsten Wochen an.
Für die Fahrzeiten der Rolladen denke ich mir da folgenden Ansatz:
- Die Auf- und Abfahrzeiten sind unterschiedlich, wegen der Last der Rolladen.
- Ich würde auch die Fahrzeit von ganz geschlossen, bis zur Position wo die untere Kante des Rolladen gerade noch aufliegt, aber alle Lamellen schon auseinander gezogen sind, berücksichtigen (Lüftungsposition)
- Und dann noch die gespeicherte Position für den "stop" (go-my) Befehl.
Ist das übrigens so gewollt?
Meine Rolladen gehen mit "on" nach unten. Ich hätte das eigentlich anders herum erwartet.
Bei den Fahrtpositionen müssen wir uns noch einigen, was 0 und was 100 bedeutet.
Bei meiner Markise habe ich 0 als eingefahren und 100 als komplett ausgefahren definiert.
Gruß
Elektrolurch
Zitat von: Elektrolurch am 13 Juli 2014, 09:46:09
Hallo Thomas,
den Account habe ich unter "Elektrolurch" angelegt. Mal sehen, ob ich mit der Seite zurecht komme, da ichh auf einen Screenreader angewiesen bin und da scheinen einige Links nur als Ikon vorhanden zu sein.
Hallo,
super, ich habe dich hinzugefügt.
Das mit der Seite tut mir leid, ich wusste nicht, dass du einen Screenreader nutzt.
Zum Arbeiten brauchst du die github-Seite aber nicht, das geht alles von der Kommandozeile aus oder mit einem grafischen Tool.
Hast du schon "git" als Versionskontrollsystem genutzt?
Wenn nicht, gibt es eine gute kurze Anleitung hier: http://rogerdudler.github.io/git-guide/ (http://rogerdudler.github.io/git-guide/)
Grob gesagt: Repository clonen, deine Änderungen vornehmen, committen, und mit "git push" mir wieder zur Verfügung stellen.
Zitat
Mit den "sub - Adressen" wäre natürlich eleganter, da gebe ich Dir recht, aber das geht dann schon wieder tiefer in den Code hinein, den Du geschrieben hast.
Ich habe mir in letzter Zeit bei der readingsGroup die HTML-Erzeugung angesehen und ich denke, dasss man da einen Teil aus dem dummy-Modul verwenden könnte. Ich sehe mir mal das in den nächsten Wochen an.
Die Subadressen sind eine erste Idee von mir - ich hab das noch nicht tiefer durchdacht, vielleicht funktioniert es gar nicht.
Da bin ich für Vorschläge offen.
Zitat
Für die Fahrzeiten der Rolladen denke ich mir da folgenden Ansatz:
- Die Auf- und Abfahrzeiten sind unterschiedlich, wegen der Last der Rolladen.
- Ich würde auch die Fahrzeit von ganz geschlossen, bis zur Position wo die untere Kante des Rolladen gerade noch aufliegt, aber alle Lamellen schon auseinander gezogen sind, berücksichtigen (Lüftungsposition)
- Und dann noch die gespeicherte Position für den "stop" (go-my) Befehl.
Finde ich gut so! Die Zeit für die go-my Position musst du aber nicht speichern, das macht der Rolladen ja intern selbst.
Zitat
Ist das übrigens so gewollt?
Meine Rolladen gehen mit "on" nach unten. Ich hätte das eigentlich anders herum erwartet.
Bei den Fahrtpositionen müssen wir uns noch einigen, was 0 und was 100 bedeutet.
Bei meiner Markise habe ich 0 als eingefahren und 100 als komplett ausgefahren definiert.
Ja, das ist gewollt, scheint die gängige Konvention in FHEM zu sein.
In den anderen Modulen (Homematic, FS20) ist es auch so, on = Rollo zu, off = Rollo offen.
Über eventmap kann man das aber nach Belieben anpassen.
Die Prozente sind laut FHEMWiki (http://www.fhemwiki.de/wiki/Slider_f%C3%BCr_HM-Rollladensteuerung_anzeigen (http://www.fhemwiki.de/wiki/Slider_f%C3%BCr_HM-Rollladensteuerung_anzeigen)) wie folgt: 100% = Rollo offen, und 0% = Rollo geschlossen.
Das deckt sich auch mit den verfügbaren Icons in FHEM (wd_blk_shutter_open.png und wd_blk_shutter_closed.png).
Ist aber leider genau andersherum als bei deiner Markise...
Grüße,
Thomas
Hallo Thomas,
mit dem repository habe ich mich noch nicht beschäftigt, werde mir mal den Link ansehen und schauen, was ich da auf Kleinweich Win 8 brauche.
Zitat:
- Und dann noch die gespeicherte Position für den "stop" (go-my) Befehl.
Finde ich gut so! Die Zeit für die go-my Position musst du aber nicht speichern, das macht der Rolladen ja intern selbst.
Na, um einen go-my - Befehl bezüglich der Positionsanzeige in fhem richtig zu tracken, muss man ihn speichern.
Habe bezüglich der Ausgabe für einen Rolladen über die fhem-web mal ein wenig herum gestöbert. Irgendwie hat das wohl etwas mit der fw_summary zu tun, die man als Modul einhängen kann. Muss mal sehen, ob ich da verständliche Beispiele finde. Im dummy ist da nichts drin, wie ich ursprünglich dachte....
Gruß
Elektrolurch
Hallo zusammen,
ich hänge hier mal die erste Erweiterung an den post an.
Was ist neu?
1. Man kann nun auch die Rolladen über einen Positionswert verfahren. Dazu wurde das set-Kommando erweitert und vier Attribute eingeführt. Die müssen allerdings gesetzt sein, damit das "set <device> pos <wert> auch funktioniert.
<Wert> ist zwischen 0 (=offen) und 100 (der Rolladen verdeckt zu 100 % das Fenster, steht aber noch auf Lüftung).
Außerdem versteht das set nun auch "open" (=off) und "close" (=on).
Um die Fahrtzeiten der Rolladen korrekt zu errechnen, sind folgende 'Attribute zu setzen:
drive-down-time.to-100: Die Zeit von ganz "offen" bis "Rolladen ist gesperrt" (nicht in der Endposition "close")
drive-down-time-to-close: Die Fahrtzeit herunter von ganz "open" zu ganz "close". Ist meist um 3 - 5 Sekunden größer als "drive-down-time-to-100".
drive-up-time-to-100: Zeit von Endposition "close" bis zur Sperrposition- Meist 3 bis 5 Sekunden.
drive-up-time-to-open: Zeit für das Hochfahren von der Endposition "close" bis "open".
Die gewünschte Position wird dann über den set-Befehl in Fahrtzeit umgerechnet und auf den "state" des Devices abgebildet (in 10er-Schritten), damit kann man sich die Position auch über ein Ikon darstellen lassen:
devStateIcon close|pos.100:fts_shutter_100:open pos.90:fts_shutter_90:open pos.80:fts_shutter_80:open pos.70:fts_shutter_70:open pos.60:fts_shutter_60:open pos.50:fts_shutter_50:open pos.40:fts_shutter_40 pos.30:fts_shutter_30 pos.20:fts_shutter_20 pos.10:fts_shutter_10 open|pos.0:fts_shutter_10
drive-down-time-to-100 12.56
drive-down-time-to-close 16.90
drive-up-time-to-100 3.18
drive-up-time-to-open 18.27
eventMap /open:offen/close:geschlossen/pos 100:gesperrt/pos 90:Dämmerung/pos 80:Sonnenschutz/
group Rolladen
room Arbeitszimmer
verbose 3
webCmd offen:gesperrt:geschlossen:pos
# Damit gibt es ein Menü für die Positionsauswahl
Über das Event-Map geht dann auch so was:
set AzFRolladen Sonnenschutz
Problem:
Die Fahrzeiten sind abhängig von der Position, d.h. beim Herunterfahren wird der Rolladen immer schneller, je weiter er herab fährt. Umgekehrt beschleunigt er, je weiter er bereits Hochgefahren ist.
Im Ergebnis steht der Rolladen an einer etwas anderen Stelle, wenn er von ganz "offen" auf "pos 50" heruntergefahren wird, als wenn von ganz "geschlossen" auf "pos 50" gefahren wird.
Dazu lasse ich mir aber noch ev. etwas einfallen. Für die ersten "Spielereien ist es erst einmal genau genug.
Die "alten" set - Befehle on,off,on-for-timer,off-for-timer funktionieren auch noch.
Ich habe allerdings den state geändert, der wiederspiegelt nun die Position des Rolladen wieder.
@Thomas: Ich habe mir den Stand vom git herunter geladen, leider klappte es aber nicht mit dem einchecken der neuen Version. Ich denke, dass ich da in meinem git irgendwo den Usernamen hinterlegen muss.Leider steht da nix zu in der Kurzanleitung.
Leider kann ich keine CULF programmieren, sobald aber auch der Empfang von Somfy RTS - Signalen implementiert wurde, werde ich das Modul so erweitern, dass die Rolladen auch dann in fhem die korrekte Position haben, wenn sie über eine Somfy-FB verfahren wurden. Habe da schon ein wenig vorarbeit in dem Modul geleistet.
Änderung: Der state wird nun nach Erreichen der Position erst berechnet, auf Basis der Zeit zwischen dem on/off - Befehl und dem Stop-Befehl, dadurch geht die Positioniererei schon deutlich präziser.
Gruß
Elektrolurch
Hallo Elektrolurch,
super Arbeit, ich danke dir!
Ich habe es jetzt in github eingecheckt, teste es jetzt noch bei mir zuhause, und werde es danach in den FHEM-Code einchecken.
Bei der CULFW kann ich evtl. helfen, ich habe den Sende-Modus ja schon implementiert - Empfang ist leider etwas umfangreicher.
Grüße, Thomas
Hallo Thomas,
schön, dass es gefällt. Über die Funktion SOMFY_UpdateNewPos habe ich schon die "Vorarbeit" getroffen, damit man auch bei der Bedienung der Somfys über andere FBs die Position richtig tracken kann. Der letzte Durchbruch war am Sonntag, als ich herausgefunden habe, dass der InternalTimer ja auch Nachkommastellen verarbeiten kann, dass hat die ganze Positioniererei schon vereinfacht.
Habe heute noch eine kleine Nachbesserung vorgenommen, bei den Befehlen open und close fährt ja der Rolladen ohne Zeitsteuerung immer auf eine definierte Endposition, da kann ich mir das Berechnen ja sparen, dass habe ich noch heute eingepflegt, muss es aber noch testen, bevor ich es hochlade.
Habe die Fahrtzeiten der Rolladen gestern noch Mal genau gemessen und festgestellt, dass die bei gleichem Fenstertyp doch leicht variieren. Aber die Position wird jetzt so genau angefahren, dass man sie mit einem Metermaß nachmessen kann.
Frage: Welche Befehle muss ich in der Kommandozeile von gitap eingeben, damit ich die Versionen auch hochladen kann?
Leider, wie schon weiter oben gesagt, muss ich wohl ihm den Benutzer und den Zugriff auf Dein gitap beibringen, steht aber nicht in der Kurzanleitung.
Vielleicht ist auch die Zeitsteuerung / Programmierung von interesse, die ich hier im Forum hochgeladen habe. Da sind ein paar ganz nette Spielereien drin und die Anpassungen habe ich dokumentiert.
Gruß
Elektrolurch
Zitat von: Elektrolurch am 19 August 2014, 12:17:52
Frage: Welche Befehle muss ich in der Kommandozeile von gitap eingeben, damit ich die Versionen auch hochladen kann?
Bei github muss man erst seinen SSH-Key rüberkopieren, danach kann man mit "git commit" und "git push" seine Sachen wieder hochladen.
Ich denke es geht am einfachsten mit der App: https://windows.github.com/
Die kannst du herunterladen, und dann auf der Projektseite (https://github.com/thdankert/somfy-rts-fhem) "Clone in Desktop" drücken.
Danach kopierst du dein SOMFY-Modul rein, und die App sollte die Änderungen erkennen.
Dann einfach Committen und in der App auf "Sync" drücken.
Wenn du noch Fragen dazu hast, meld dich nochmal (gern auch per PN, dann versuchen wir es so).
Grüße,
Thomas
Die app hatte ich mir schon installiert, die scheint aber mit einem webkit programmiert worden zu sein, so dass mein ScreenReader schweigt und ich das Teil nicht bedienen kann.
Bei dem Kommandozeilen-Tool ist es leider so, dass die Hilfetexte so schnell durchlaufen, so dass ich die nicht "mental auswerten" kann.
Mit dem ssh-key klingt irgendwie etwas aufwendig....
Gruß
Elektrolurch
Hallo Elektrolurch,
entschuldige, ich habe nicht daran gedacht, dass du einen Screenreader nutzt.
Versuchs mal so (Git den richtigen Nutzernamen + Email beibringen):
https://help.github.com/articles/set-up-git#platform-windows
Hier nochmal fürs Terminal:
git config --global user.name "YOUR NAME"
git config --global user.email "YOUR EMAIL ADDRESS"
Und dann den Clone über HTTPS:
https://help.github.com/articles/which-remote-url-should-i-use#cloning-with-https-recommended
Bei dieser Methode muss man keine SSH-Keys irgendwohin kopieren, es wird stattdessen das Github-Passwort abgefragt.
Darüber kannst du den Clone machen (auch ohne die github-App, einfach von der Kommandozeile).
Grüße
Hallo Thomas,
die von mir programmierte Positionierbarkeit der Rolladen läuft jetzt schon seit einiger Zeit ohne Probleme. Ich habe heute per "update check" gesehen, dass Du die Änderungen am Modul noch nicht offiziell in die fhem-contribution eingestellt hast. Gibt es einen Grund dafür?
Vorher mal bitte checken, ob ich hinten die erweiterten Attribute in dem html - Teil richtig beschrieben habe.
Was jetzt bei mir noch etwas störend ist, dass ich ja nicht mitbekomme, wenn ein Rolladen von einer anderen FB aus gesteuert wird. Dafür müsste ja die CULF auch um einen Empfangsteil erweitert werden. Hast Du da schon was gemacht?
Um den Teil im Modul würde ich mich dann versuchsweise (:-= mal kümmern wollen.
Gruß
Elektrolurch
Hi,
da steckt keine Absicht dahinter, ich hatte nur noch keine Zeit, das einzubauen und einzuchecken.
Zum Empfang: das ist umfangreicher als reines Senden, vielleicht schaff ich das über Weihnachten, in die CULFW zu integrieren.
Hallo ihr beiden.
Ich teste gerade das Modul von Elektrolurch habe aber ein paar Probleme.
Meine on/off-for-Timer gehen nicht mehr mit dem neuen Modul. Bei Benutzung verhalten sie sich wie on/off.
Das runterfahren zu einer Position mit pos geht gut aber das nach oben nicht. Bin ich beispielsweise auf pos 80 und möchte danach auf pos 20 so bewegt sich der Laden nur ganz kurz und nichts weiteres passiert mehr.
Viele Grüsse Ben
Hallo,
dass mit on-for-timer sehe ich mir mal an.
Stimmt: Der Rolladen fährt bis zur Endposition, also ohne timer.
Hatte ich nicht mehr getestet, weil ja "pos" das tut, was ich brauche.
Das Runter- und Hochfahren habe ich jetzt seit mehreren Wochen in Benutzung.
Möglicherweise hast Du die Zeiten vielleicht nicht richtig eingegeben?
Es sind ja 4 Zeiten zu hinterlegen:
1. Die Zeit von offen bis zu jenem Punkt bei dem der Rolladen gerade die untere Kante berührt, also die Lamellen noch nicht zusammen geschoben sind.
Beispiel 15 sec
2. Die Zeit von offen bis ganz geschlossen - Beispiel 20 sec.
3. Die Zeit von ganz geschlossen bis zu jener Position, wo die untere Kante des Rolladens gerade das Fenster berührt, Beispiel 5.5 sek.
3
4. Die Zeit von ganz geschlossen bis ganz offen, Beispiel 21.5 s
Mit "verbose 4" sollten berechnete Werte angezeigt werden.
Gruß
Elektrolurch
Hallo Electrolurch,
Danke für die Tipps konnte aber keine Lösung finden. Habe / hatte alle vier Zeiten angegeben gehabt und mehrfach getestet. Unten ein Beispiel. Habe für open-to-100 und close-to-100 jeweils 25 sec vergeben und für die anderen beiden jeweils 27. dann habe ich aus geöffnetem Zustand auf pos 100 bewegt. Alles gut soweit 25 sec. Dann habe ich auf pos 20 bewegt und nur 1.6 sec drive Time bekommen (siehe log Auszug unten).
2014.09.16 23:35:54 3: somfy_set: cmd on newpos 100 drivetime 25
2014.09.16 23:35:54 2: SOMFY set RolloSchlaZi on 100: YsA3400013111004
2014.09.16 23:35:54 2: SOMFY IODev device didn't answer Ys command correctly: raw => Yr:2
2014.09.16 23:35:54 0: ERROR: Cannot autoload SOMFY
2014.09.16 23:35:54 3: CUL_Ben: Unknown code YsA3E9E9FAFEEEFF, help me!
2014.09.16 23:35:54 0: ERROR: Cannot autoload SOMFY
2014.09.16 23:35:54 3: CUL_Ben: Unknown code Yr:6, help me!
2014.09.16 23:36:19 2: SOMFY set RolloSchlaZi stop: YsA4110014111004
2014.09.16 23:36:19 2: SOMFY IODev device didn't answer Ys command correctly: raw => Yr:2
2014.09.16 23:36:19 0: ERROR: Cannot autoload SOMFY
2014.09.16 23:36:19 3: CUL_Ben: Unknown code YsA4BBBBAFABBBAA, help me!
2014.09.16 23:36:19 0: ERROR: Cannot autoload SOMFY
2014.09.16 23:36:19 3: CUL_Ben: Unknown code Yr:6, help me!
2014.09.16 23:36:36 3: somfy_set: cmd off newpos 20 drivetime 1.6
2014.09.16 23:36:36 2: SOMFY set RolloSchlaZi off 20: YsA5200015111004
2014.09.16 23:36:36 2: SOMFY IODev device didn't answer Ys command correctly: raw => Yr:2
2014.09.16 23:36:36 0: ERROR: Cannot autoload SOMFY
2014.09.16 23:36:36 3: CUL_Ben: Unknown code YsA589899C988899, help me!
2014.09.16 23:36:36 0: ERROR: Cannot autoload SOMFY
2014.09.16 23:36:36 3: CUL_Ben: Unknown code Yr:6, help me!
2014.09.16 23:36:37 2: SOMFY set RolloSchlaZi stop: YsA6110016111004
2014.09.16 23:36:38 2: SOMFY IODev device didn't answer Ys command correctly: raw => Yr:2
2014.09.16 23:36:38 0: ERROR: Cannot autoload SOMFY
2014.09.16 23:36:38 3: CUL_Ben: Unknown code YsA6B9B9AFABBBAA, help me!
2014.09.16 23:36:38 0: ERROR: Cannot autoload SOMFY
Irgendwas scheint da falsch zu rechnen, zumindest bei mir. Mir ist zudem aufgefallen, wenn ich das Attribut down-to-100 setze, das das Attribut für down-to-close automatisch auf die gleiche Zeit gesetzt wird. Das passiert aber nur wenn down-to-close noch nicht gesetzt ist und scheint mir logisch. Bei up-to-100 und up-to-open ist das nicht so. Ist das normal?
Grüsse Ben
Zitat von: Bensen9 am 16 September 2014, 23:49:14
Hallo Electrolurch,
Danke für die Tipps konnte aber keine Lösung finden. Habe / hatte alle vier Zeiten angegeben gehabt und mehrfach getestet. Unten ein Beispiel. Habe für open-to-100 und close-to-100 jeweils 25 sec vergeben und für die anderen beiden jeweils 27. dann habe ich aus geöffnetem Zustand auf pos 100 bewegt. Alles gut soweit 25 sec. Dann habe ich auf pos 20 bewegt und nur 1.6 sec drive Time bekommen (siehe log Auszug unten).
2014.09.16 23:35:54 3: somfy_set: cmd on newpos 100 drivetime 25
2014.09.16 23:35:54 2: SOMFY set RolloSchlaZi on 100: YsA3400013111004
2014.09.16 23:35:54 2: SOMFY IODev device didn't answer Ys command correctly: raw => Yr:2
2014.09.16 23:35:54 0: ERROR: Cannot autoload SOMFY
Grüsse Ben
Hallo Ben,
ich habe den Code von Elektrolurch leider noch nicht selbst im Einsatz, kann dazu also nicht viel sagen.
Aber das oben sieht so aus, als kommt die "repetition" dazwischen (Yr = setze repetition).
Wenn ein Kommando gesendet wird, wird zuerst geprüft, ob die repetition gesetzt werden muss.
Das passiert, aber der Code erwartet zu diesem Zeitpunkt bereits eine Antwort auf sein Ys (= Bewegungskommando), bekommt aber nur Yr.
Lösch mal testweise das Attribut repetition (ich weiß, dann bewegen sich die Läden nicht mehr richtig, ist nur zum Test).
Grüße,
Thomas
Hi Thomas,
Das passiert wenn ich erst mit repetition 2 auf "off" und dann "stopp" gehen und als drittes nach gelöschtem repetition einmal "on" mache.
Komisch die ganzen Meldungen sind dann weg. Kannst du das vielleicht mal im Detail erklären.
2014.09.18 00:57:42 3: SOMFY_set: RolloSchlaZi -> state update in 26.97 sec
2014.09.18 00:57:42 2: SOMFY set RolloSchlaZi off: YsA5200025111004
2014.09.18 00:57:42 2: SOMFY IODev device didn't answer Ys command correctly: raw => Yr:2
2014.09.18 00:57:43 0: ERROR: Cannot autoload SOMFY
2014.09.18 00:57:43 3: CUL_Ben: Unknown code YsA58A8AAFABBBAA, help me!
2014.09.18 00:57:43 0: ERROR: Cannot autoload SOMFY
2014.09.18 00:57:43 3: CUL_Ben: Unknown code Yr:6, help me!
2014.09.18 00:57:51 1: SOMFY_set: go-my/stop not correct implemented for correct positioning! Use set device pos <value> instead
2014.09.18 00:57:51 1: SOMFY_set: Error - drivetime and updatetime = 0
2014.09.18 00:57:51 2: SOMFY set RolloSchlaZi stop: YsA6110026111004
2014.09.18 00:57:51 2: SOMFY IODev device didn't answer Ys command correctly: raw => Yr:2
2014.09.18 00:57:52 0: ERROR: Cannot autoload SOMFY
2014.09.18 00:57:52 3: CUL_Ben: Unknown code YsA6BABA9C988899, help me!
2014.09.18 00:57:52 0: ERROR: Cannot autoload SOMFY
2014.09.18 00:57:52 3: CUL_Ben: Unknown code Yr:6, help me!
2014.09.18 00:58:09 1: SOMFY_CalcNewPos: RolloSchlaZi move wrong stop
2014.09.18 00:59:44 3: SOMFY_set: RolloSchlaZi -> state update in 2 sec
2014.09.18 00:59:44 2: SOMFY set RolloSchlaZi on: YsA7400027111004
Danke und viele Grüsse Ben
Hallo Bensen9,
schau Dir mal oben mein Zahlenbeispiel für die Fahrzeiten an, Dein dritter Wert (drive-time-up-to-100) ist falsch.
Nochmal zur Messung der Fahrzeiten:
1. Man nehme eine Stopuhr mit Zwischenzeiten
2. Der Rolladen ist oben.
3. Man drücke down und starte die Stopuhr.
4. Wenn der Rolladen gerade die untere Fensterkante berührt, nimmt man die erste Zwishenzeit (drive-down-time-to-100).
5. Ist das Rollo ganz geschlossen, stoppt man (drive-down-time-to-close)
5. Stopuhr zurücksetzen.
6. Up am Rollo starten und stoppuhr starten.
7. Wenn das Rollo gerade die untere Fensterkante nicht mehr beührt, also alle Lamellen gespreizt sind, nimmt man die Zwischenzeit (drive-up-time-to-100). Das können nur wenige Sekunden sein und nicht wie bei Dir mehr als 15 Sekunden.
8. Wenn der Rolo die obere Endposition erreicht hat, drückt man Stop auf der Stoppuhr. (drive-up-time-to-open).
Will man es nicht so genau haben, mit dem Grad der Verschattung des Fensters, so kann man:
drive-down-time-to-100 = drive down-time-to-close und
drive-up-time-to-100 = 0 setzen.
drive-down-time-to-close und drive-up-time-to-open werden sich trotzdem etwas unterscheiden, da das Rollo etwas länger braucht, um hoch zu fahren.
Gruß
Elektrolurch
Hallo,
habe heute nach ca. 14 Tagen ein Update von fhem gemacht, 10_SOMFY war aber schon vorher aktuell.
Nun bekomme ich folgende Fehlermeldungen im log:
2014.10.17 19:00:54 2: SOMFY set Wz_FRolladen on: sAD40010D202101
2014.10.17 19:00:54 2: SOMFY set Wz_TRolladen on: sA2400122202100
2014.10.17 19:00:54 0: ERROR: Cannot autoload SOMFY
2014.10.17 19:00:55 0: ERROR: Cannot autoload SOMFY
2014.10.17 19:00:56 0: ERROR: Cannot autoload SOMFY
2014.10.17 19:00:57 0: ERROR: Cannot autoload SOMFY
2014.10.17 19:00:58 0: ERROR: Cannot autoload SOMFY
2014.10.17 19:00:59 0: ERROR: Cannot autoload SOMFY
2014.10.17 19:01:00 0: ERROR: Cannot autoload SOMFY
2014.10.17 19:01:01 0: ERROR: Cannot autoload SOMFY
2014.10.17 19:01:02 0: ERROR: Cannot autoload SOMFY
Ich habe dann auch noch eine Meldung bekommen, dass der Sendebuffer des CUL_433 etwas unbekanntes enthielt:
2014.10.17 18:49:16 1: CUL_433 UNKNOWNCODE YsA81D0128003420 Inhalt des CUL_0 Sendebuffers: CUL_433 raw => 540F:4128
2014.10.17 18:49:18 1: >CUL_433 buffer 540F:4128
2014.10.17 18:49:18 1: culreset: t 540F:4128 code 540F
2014.10.17 18:49:18 0: Server shutdown
Die Meldung: Cannot Autoload Somfy läßt sich derzeit reproduzieren.
(Bei jedem Verfahren der Rolladen)
Das einzige, was ich derzeit im 10_SOMFY.pm - Modul abgeändert habe, ist das ich die ParseFN auskomentiert habe, da sie mir den Status von Positionierten Rolladen überschreibt und ich schon intensiv Gebrauch von Zwischenpositionen für Sonnenschutz oder "sanftes Wecken" mache und den Status auch abfrage und auswerte, bzw. die entsprechenden Icons für die Anzeige verwende.
Auf was ist die Meldung "cannot Autoload..." zurückzuführen?
Gruß
Elektrolurch
Hallo zusammen,
ich habe gestern das SOMFY Modul ausprobiert...
1. Bei den Rolläden klappt es super gut! Das Paring hat geklappt und das anfahren der Position nach den Angaben der Zeiten.
Allerdings wenn ich zwei Stück gleichzeitig anfahren lassen will, werden sie versetzt angesteuert, also mit "set roll1,roll2 pos 50".
Dann fährt erst roll1 los, eine kurze Zeit später, 1 Sekunde oder so roll2.
Mit der Original Remote Kontroll fahren sie exakt syncron.
2. Die Raffstores konnte ich pairen, aber die Ansteuerung funktioniert gar nicht.
Um sie rauf und runter zu fahren, muß der Knopf bei den Funkschaltern >2 Sekunden gedrückt bleiben.
Wie bekommt man das angesteurt? on-for-timer klappt nicht (habe die aktuellste SOMFY Version mit update).
Um die Lamellen zu bewegen, muß man exakt kurz rauf oder runter drücken.
Das normale on oder off ist dafür schon fast zu lang.
Habt ihr da Tips?
3. Ich habe auch noch SOMFY Funksteckdosen. Die bekomme ich aktuell noch nicht gepairt.
Da wollte ich aber nochmal ein wenig rumprobieren.
Hat das schon jemand hinbekommen?
Viele Grüße!
Hallo,
Zitat:
Allerdings wenn ich zwei Stück gleichzeitig anfahren lassen will, werden sie versetzt angesteuert, also mit "set roll1,roll2 pos 50".
Dann fährt erst roll1 los, eine kurze Zeit später, 1 Sekunde oder so roll2.
Das liegt in der Natur der Sache: Zwei devices heißt auch zweimal einen Funkbefehl senden und dazwischen wird jas jeweils auch etwas gerechnet....
Das mit den Lamellen ist bekannt, da findest Du etwas im Thema:
"Erweiterung CULF um SOMFY..."
Gruß
Elektrolurch
Hallo Merlin,
Elektrolurch hat ja gerade schon geantwortet.
Ich hätte nur eine Bitte: da deine Fragen nichts direkt mit der Entwicklung des Moduls zu tun haben,
stell sie dann bitte im User-Thread http://forum.fhem.de/index.php?topic=24158 (http://forum.fhem.de/index.php?topic=24158) - damit bleibt dieser Entwickler-Thread hier sauber.
Zitat von: Merlin1 am 07 November 2014, 11:51:20
2. Die Raffstores konnte ich pairen, aber die Ansteuerung funktioniert gar nicht.
Um sie rauf und runter zu fahren, muß der Knopf bei den Funkschaltern >2 Sekunden gedrückt bleiben.
Wie bekommt man das angesteurt? on-for-timer klappt nicht (habe die aktuellste SOMFY Version mit update).
Um die Lamellen zu bewegen, muß man exakt kurz rauf oder runter drücken.
Das normale on oder off ist dafür schon fast zu lang.
Habt ihr da Tips?
Versuch mal die "repetition" (als Attribut des Device in FHEM) zu setzen - Standard ist 6x,
aber für "kurz rauf/runter" kannst du es mal mit 2 versuchen. Damit waren einige Nutzer erfolgreich!
Andersrum funktioniert es nicht so einfach, der lange Tastendruck lässt sich noch nicht richtig nachstellen.
Du kannst es gern mal mit repetition=12 oder sogar mehr versuchen.
Zitat
3. Ich habe auch noch SOMFY Funksteckdosen. Die bekomme ich aktuell noch nicht gepairt.
Da wollte ich aber nochmal ein wenig rumprobieren.
Hat das schon jemand hinbekommen?
Leider habe ich zuhause nur Rollos und keine Funksteckdosen, und kann da nichts testen.
Wie werden die normalerweise gepaired mit einer echten Fernbedienung?
Grüße,
Thomas
Es gibt Neuigkeiten: ein paar Leute haben das Protokoll weiter entschlüsselt und dabei die Bedeutung der zusätzlichen Codes rausgefunden:
Folgende Codes gibt es laut dieser Liste: http://pushstack.wordpress.com/somfy-rts-protocol/ (http://pushstack.wordpress.com/somfy-rts-protocol/)
Value Button(s) Description
0x1 My Stop or move to favourite position
0x2 Up Move up
0x3 My + Up Set upper motor limit in initial programming mode
0x4 Down Move down
0x5 My + Down Set lower motor limit in initial programming mode
0x6 Up + Down Change motor limit and initial programming mode
0x8 Prog Used for (de-)registering remotes, see below
0x9 Sun + Flag Enable sun and wind detector (SUN and FLAG symbol on the Telis Soliris RC)
0xA Flag Disable sun detector (FLAG symbol on the Telis Soliris RC)
Zitat von: thdankert am 07 November 2014, 12:15:37
Leider habe ich zuhause nur Rollos und keine Funksteckdosen, und kann da nichts testen.
Wie werden die normalerweise gepaired mit einer echten Fernbedienung?
Erstmal vielen Dank, probiere ich später aus und den Thread halte ich gern sauber, wenn so tolle Sachen entwickelt werden :)
Die Funksteckdosen werden ganz normal gepaired wie alle SOMFY RTS Geräte. Haben einen PROG Knopf und dann mit "up" und "down" ein und ausgeschaltet. "my" hat keine Funktion.
Wow... ein SOMFY Modul in FHEM klingt einfach super.
Damit könnte ich auf einen Schlag alle meine Rollos steuern.
Jetzt habe ich dazu aber eine kleine Frage.
Ich verwendet derzeit ein Brematic Gateway, das auf 433 Mhz kommuniziert, um Intertechno Steckdosen anzusteuern.
Der Grund, weshalb ich mich gerade für dieses Gateway und für keine CUL entschieden habe, ist dass mein FHEM-Server sendetechnisch sehr ungut (im Keller) steht und es mir damit nicht möglich wäre, meine Steckdosen im OG zu schalten.
Mit dem Gateway (welches über LAN mit dem Server verbunden ist), geht das aber super, da es einfach im OG aufgestellt ist :-)
Ist es denn derzeit möglich, mit dem Brematic GW die SOMFY-Rollos anzusprechen?
Wenn nein, wie könnte ich denn mein Sendeproblem lösen (mir fällt derzeit nur ein USB-LAN Extender ein).
Zitat von: Niko_K am 31 Dezember 2014, 18:13:32
Jetzt habe ich dazu aber eine kleine Frage.
Ich verwendet derzeit ein Brematic Gateway, das auf 433 Mhz kommuniziert, um Intertechno Steckdosen anzusteuern.
Ist es denn derzeit möglich, mit dem Brematic GW die SOMFY-Rollos anzusprechen?
Wenn nein, wie könnte ich denn mein Sendeproblem lösen (mir fällt derzeit nur ein USB-LAN Extender ein).
Hallo Niko_K,
vorab: deine Frage ist im Anwender-Thread besser aufgehoben http://forum.fhem.de/index.php/topic,24158.420.html (http://forum.fhem.de/index.php/topic,24158.420.html), hier geht es rein um die Weiterentwicklung des Moduls.
Deshalb hier ganz kurz: nein, das wird nicht funktionieren, das Gateway ist für Funktsteckdosen ausgelegt, und ich sehe anhand der Produktbeschreibung keine Möglichkeit, eigene Funktelegramme abzusenden.
Somfy verwendet zwar die gleiche Frequenz, aber ein völlig anderes Protokoll.
Mögliche Lösungen: CUNO (von Busware), oder langes USB-Kabel, oder 2. Raspberry PI mit FHEM+CUL an günstigerer Stelle im Haus.
Grüße,
Thomas
Hallo,
Experimentiere mit meiner Raffstore Steuerung die bekanntermaßen immer nur eine Sekunde fährt.
Änderung von Repetition, egal in welche Richtung, bringt nichts.
Das Problem liegt in der Länge des gesendeten Signals. Wenn ich kurz auf meiner Fernbedienung drücke fährt er in die gewünschte Richtung. Bei langem Druck, solange wie gedruckt.
M.M.n. muss das Signal kurzer gesendet werden. Ob/wie das geht müsst ihr wissen :)
Ich hoffe das hilft weiter.
Hallo Realkeule,
Zitat von: realkeule am 26 Februar 2015, 18:42:04
Das Problem liegt in der Länge des gesendeten Signals. Wenn ich kurz auf meiner Fernbedienung drücke fährt er in die gewünschte Richtung. Bei langem Druck, solange wie gedruckt.
M.M.n. muss das Signal kurzer gesendet werden.
soweit waren wir ja schon (siehe der Beitrag etwas weiter oben) - bei manchen Nutzern hat es mit "repetition" auf 1 oder 2 funktioniert, den kurzen Tastendruck nachzuahmen.
Leider habe ich keine Raffstore, nur normale Rolläden, und bisher konnte mir noch keiner das Signal seiner Fernbedienung aufzeichnen...
Grüße,
Thomas
Stimmt, ich hatte das von Merlin irgendwie andersherum verstanden. Egal:
Sag mir wie ich das Signal aufzeichne und ich zeichne es dir auf :)
//edit
alles ist gut. heute nochmal in ruhe damit gearbeitet und eine lösung (die hier beschrieben ist) gefunden!
repitition 3 ist der maximale (und auch sicherster!) wert. damit lässt sich alles steuern. habe 14 raffstores die einzeln angelernt sind und eine große gruppe mit allen raffstores und alle funktionieren besser als mit der original fernbedienug.
ich bin erstmal glücklich und stürze mich jetzt auch den automatismus!
vielen dank :)
Hallo,
ich bin begeistert von dem Somfy Modul. Als ich mit Fhem anfing, war das das erste Modul das eingebunden wurde, da mein Haus komplett mir Somfy Funk Rollladen bestückt ist. Seit dem optimiere ich die Steuerung ständig und versuche immer mehr intelligente Funktionen zu realisieren.
Da die aktuell eingecheckte Version 1.5 viele Problem mit der Auswertung der Position über state aufwirft und deshalb meine Doif´s immer wieder Mist bauen, war ich voller Erwartung als ich durch Zufall auf GitHub eine Version 1.6 gefunden hatte.
Nun habe ich diese dann zu Testen von Hand Installiert und festgestellt das das mit den Positionen schon seeehr viel besser funktioniert. :)
Leider stürzt allerdings nach einigen Fahrbefehlen mein auf dem RASPI laufendes Fhem ab. Und ich bekomme beim starten immer folgende Meldungen:
Prototype mismatch: sub main::max ($@) vs (@) at /usr/share/perl/5.14/Exporter.pm line 67, <$fh> line 398.
at ./FHEM/10_SOMFY.pm line 55
Prototype mismatch: sub main::min ($@) vs (@) at /usr/share/perl/5.14/Exporter.pm line 67, <$fh> line 398.
at ./FHEM/10_SOMFY.pm line 55
Irgend was scheint da mit meinem Perl Exporter nicht zu harmonieren. Was kann ich tun um das zum laufen zu bringen ?
Ist da im Somfy Modul noch ein Fehler, oder muß ich an meiner Perl Installation was ändern ?
Ich hoffe das dann auch die Abstürze vorbei sind.
Die Version 1.6 macht seine Sache soviel besser als die 1.5 das ich alles daransetzten werde die zum laufen zu bringen.
An dieser Stelle auch mal riesen Dank an die Mitwirkenden thdankert, Elektolurch und viegener !!!
Großen Respekt! Ich wünschte ich könnte auch so was schreiben. Aber ich bin ja schon zufrieden das ich mit Fhem so gut klarkomme. Ist schon wie ne Sucht geworden. Da ich MSR Techniker von Beruf bin kann ich auch Privat nicht anders. 8)
Ich bitte hier also dringend mal um Hilfe. Ich hoffe mir kann da jemand eine Tipp geben wie ich an der Stelle weiter komme.
---Skusi
Zitat von: Skusi am 14 Juni 2015, 09:57:36
Leider stürzt allerdings nach einigen Fahrbefehlen mein auf dem RASPI laufendes Fhem ab. Und ich bekomme beim starten immer folgende Meldungen:
Prototype mismatch: sub main::max ($@) vs (@) at /usr/share/perl/5.14/Exporter.pm line 67, <$fh> line 398.
at ./FHEM/10_SOMFY.pm line 55
Prototype mismatch: sub main::min ($@) vs (@) at /usr/share/perl/5.14/Exporter.pm line 67, <$fh> line 398.
at ./FHEM/10_SOMFY.pm line 55
Hallo Skusi,
danke für das Lob! Kannst du das Problem als Issue im Github-Projekt einstellen? Dann vergess ich das nicht (bin ab Morgen im Urlaub), und kann nach einer Lösung suchen.
Grüße,
Thomas
Hallo Thomas,
danke für die schnelle Reaktion.
Ich habs bei GiHub eingestellt (hoffentlich richtig ?) !
Hab ich Dich ja noch gerade erwischt. ;)
Da Du wohl im Urlaub nicht an Fhem schrauben wirst (-oder ?) werde ich mich wohl ein par Wochen gedulden müssen.
Naja, die Lösung zählt !!!
Ich wünsche eine erholsamen Urlaub !
---Skusi
Hallo Skusi,
Irgendwie war mir dieser Thread bisher entgangen.
Ich habe hier mal eine aktualisierte Version angehängt, in der die Fehlermeldung wohl nicht mehr auftritt.
Erklärung: min und max können normalerweise aus dem Util-Modul importiert werden, dass standardmässig bei Perl enthalten ist. Allerdings wird wohl irgendwo in FHEM eine eigene Definition von min und max gemacht, deshalb kommt es zu der Meldung.
Ich habe den use / import-Teil jetzt mal herausgenommen, das läuft bei mir bisher ohne Probleme.
Lass mich wissen, ob das auch bei Dir funktioniert.
Gruss,
Johannes
Und noch ein Hinweis: Ich habe das Problem mit den Abstürzen nicht reproduzieren können. Ich denke aber es hängt zumindest nicht mit den obigen Fehlermeldungen zusammen. Bei mir läuft FHEM auf einem pi2.
Sind die Abstürze erst mit der Version 1.6 aufgetreten und waren weg nachdem Du die 1.5 wieder eingespielt hast?
Johannes
Hallo viegener,
nun bin ich mal dazu gekommen dein angepasstes Modul auszuprobieren.
Die Fehlermeldung beim Start ist schonmal weg ! :D
Abstürze habe ich bisher auch noch nicht gehabt. Ich habe das Modul aber auch gerade erst ausgetauscht und vom Update ausgeschlossen. Die ersten Fahrbefehle sahen schon sehr gut aus. Nun haben ich auch wieder den exakten Positions State. Vielen Dank schonmal für diese Aufwertung.
Ich werde die Tage mal beobachten wie stabil die Sache läuft.
Ich betreibe Fhem übrigens auch auf einem Raspi 2.
Warum ist die 1.6 Version denn noch nicht eingecheckt ? Ist noch zu Beta ?
Ich finde die angaben des Pos im state sehr hilfreich. Schön ist dabei auch das während des fahrens nun miene StateIcons fein "mitlaufen" ;D
Vielen dank erstaml für die Unterstützung. Ich berichte wieder wenn mir was auffällt.
---Skusi
Zitat von: Skusi am 29 Juni 2015, 19:23:22
Warum ist die 1.6 Version denn noch nicht eingecheckt ? Ist noch zu Beta ?
Soweit ich gelesen habe ist Thomas noch in Urlaub und ich finde es löblich, dass er vor seinem Urlaub nicht noch schnell einen neue Version freigegeben hat, denn das kenne ich aus eigener Erfahrung: das geht gerne mal schief ;)
Hallo,
ich hatte ja meine "private" Version wegen der korrekten Anzeige und des Auskommentierens der parseFn.
Nun habe ich gestern die V1.6 vom Beitrag oben mal eingespielt und heute morgen haben wir alle verschlafen. :-D
Ich hatte dem set-Befehl die Optionen "open" und "close" noch hinzugefügt, weil ich das deutlich eingängiger als "on" und "off" für einen Rolladen sehe.
Die fehlen aber in der 1.6.
Elektrolurch
Zitat von: Elektrolurch am 30 Juni 2015, 08:49:49
Nun habe ich gestern die V1.6 vom Beitrag oben mal eingespielt und heute morgen haben wir alle verschlafen. :-D
Ich hatte dem set-Befehl die Optionen "open" und "close" noch hinzugefügt, weil ich das deutlich eingängiger als "on" und "off" für einen Rolladen sehe.
Die fehlen aber in der 1.6.
Elektrolurch
Ausschlafen tut doch auch mal gut ;D
Ich kann das gerne noch hinzufügen, ich hatte bei mir Open und close auch, habe das aber über eine eventmap realisiert:
eventMap on:close off:open stop:halt
Vielleicht hilft Dir das sogar schneller weiter?
Gruss,
Johannes
Hallo Johannes,
klar ginge das mit eventMap, daran hatte ich auch gedacht.... aber nun kommt auch noch Deutsch und Englisch hinzu:
Meine Definition zur Zeit:
eventMap /open:offen/close:geschlossen/pos 100:gesperrt/pos 80:Dämmerung/pos 70:Sonnenschutz/
Und dann muss man noch schauen, wie readingsGroup damit umgeht. 'state' und STATE meine ich.
Wenn man es einbauen könnte, fände ich es schon schöner.
Einmal bei der Ausgabe von set xxx ?
und in der set-Routine überall da, wo auf on/off abgefragt wird es mum open/close ergänzen.
So hatte ich es (so glaube ich) drin.
Elektrolurch
Hi zusammen,
Zitat von: viegener am 29 Juni 2015, 22:09:22
Soweit ich gelesen habe ist Thomas noch in Urlaub und ich finde es löblich, dass er vor seinem Urlaub nicht noch schnell einen neue Version freigegeben hat, denn das kenne ich aus eigener Erfahrung: das geht gerne mal schief ;)
Und jetzt bin ich wieder erholt zurück und wir können gern die neue Version festzurren und freigeben :)
Zitat von: Elektrolurch am 30 Juni 2015, 12:05:25
klar ginge das mit eventMap, daran hatte ich auch gedacht.... aber nun kommt auch noch Deutsch und Englisch hinzu:
Genau dafür ist eventMap da - in vielen anderen Modulen heißen die Kommandos ebenfalls on/off/stop, da möchte ich ungern die Ausnahme sein.
Englisch ist beim Programmieren einfach weiter verbreitet.
Zitat
Und dann muss man noch schauen, wie readingsGroup damit umgeht. 'state' und STATE meine ich.
@Elektrolurch: was genau meinst du? Gibt es bei Verwendung einer readingsGroup noch Probleme?
@Johannes: hast du noch weitere Änderungen gemacht, die vielleicht noch von einer größeren Nutzergruppe getestet werden sollten, bevor es eine neue Version gibt?
Wenn nicht, kann ich das gern einchecken, dann ist es morgen/übermorgen per Update verfügbar.
Grüße,
Thomas
Zitat von: thdankert am 30 Juni 2015, 20:13:09
@Johannes: hast du noch weitere Änderungen gemacht, die vielleicht noch von einer größeren Nutzergruppe getestet werden sollten, bevor es eine neue Version gibt?
Wenn nicht, kann ich das gern einchecken, dann ist es morgen/übermorgen per Update verfügbar.
Nein, ich sehe die Änderungen von oben mit dem Util package und der direkten Änderung des Status hast Du selber bereits nachgezogen (das nächste Mal bekommst Du auch einen pull request).
Also aus meiner Sicht wäre es soweit ok,
Johannes
Danke, ich habe gerade die neueste Version eingecheckt, ab morgen früh ist sie dann per FHEM update verfügbar.
Hallo Johannes,
habe die Version aus dem fhem gerade ausprobiert.
Da hat sich bezüglich der Position noch ein kleiner Fehler eingeschlichen:
Das set - Kommande akzeptiert "pos", intern (in _UpdateState) aktualisierst Du aber "position" und nicht das reading "pos".
Das hat den Effekt, dass, wenn man das Aufklappmenü pos:0...100 aus dem Modul verwendet, das Menü nach der Positioniererei nicht mehr stimmt.
Wir haben jetzt zwei gleiche readings: pos und position.
Vermutlich würde es reichen, überall wo position verwendet wird, pos zu verwenden. Dann wäre es wieder stimmig.
Alles andere muss ich über eventMap und devStateIcon anpassen.
Gruß
Elektrolurch
Zitat von: Elektrolurch am 02 Juli 2015, 14:23:00
Hallo Johannes,
habe die Version aus dem fhem gerade ausprobiert.
Da hat sich bezüglich der Position noch ein kleiner Fehler eingeschlichen:
Das set - Kommande akzeptiert "pos", intern (in _UpdateState) aktualisierst Du aber "position" und nicht das reading "pos".
Das hat den Effekt, dass, wenn man das Aufklappmenü pos:0...100 aus dem Modul verwendet, das Menü nach der Positioniererei nicht mehr stimmt.
Wir haben jetzt zwei gleiche readings: pos und position.
Vermutlich würde es reichen, überall wo position verwendet wird, pos zu verwenden. Dann wäre es wieder stimmig.
Alles andere muss ich über eventMap und devStateIcon anpassen.
Gruß
Elektrolurch
Hallo Elektrolurch,
vermutlich ist es heute zu warm, aber ich verstehe Deine Beschreibung leider nicht. Auch wenn ich "set pos" verwende, bleibt es bei mir dabei, dass ich nur ein Reading habe: position. Ich habe in den alten Stand geschaut (von Maerz) und auch dort heisst das Reading position. Kann es sein, dass das pos Reading noch woanders herkommt?
Den Unterschied, den ich finden konnte ist, dass heute in state direkt numerische Werte stehen und früher dort Einträge der Art "pos 50" standen. Das hatte ich beim Umbau übersehen. Wenn gewünscht liesse sich das sicher wieder umstellen.
Gruss,
Johannes
Hallo Johannes,
für wahr, sehr heiß.
Schau mal in den set - Befehl: Da gibt es ja
set roll pos <ein Wert>
Üblicherweise wird doch, so habe ich fhem verstanden, die Option "pos" als reading betrachtet und das Ergebnis von
set roll pos <Wert>
in das reading pos gespeichert.
Wenn Du set roll ? eingibst, so sollte ja bei einer bestimmten Option auch die Liste der möglichen Werte erscheinen, also für pos:0,10,20...,100 damit die Detailansicht auch korrekt angezeigt wird.
Eigentlich hatte ich das auch so drin, ist aber jetzt wohl weg.
Schaut dann so ungefähr so aus:
%sets = (
'on' => '',
'off' => '',
'pos' => '0,10,20,... 100',
usw
und am Ende der set-Routine für ? oder unbekannte Optionen habe ich dann so was:
else
{
my @cList;
# overwrite %sets with setList
my $atts = AttrVal($name,'setList',undef);
my %setlist = split("[: ][ ]*", $atts);
foreach my $k (sort keys %sets)
{
my $opts = undef;
$opts = $sets{$k};
if (defined($opts))
{
$opts = $setlist{$k} if(exists($setlist{$k}));
push(@cList,$k . ':' . $opts);
}
else
{
push (@cList,$k);
}
} # end foreach
return "Unknown argument $rd, choose one of " . join(" ", @cList);
} # if $rd
Damit bekommt "pos" automatisch das gewünschte Menü, kann aber per setList durch einen slider bspw. auch überschrieben werden.
Wenn ich das pos-Menü benutze, dann muss pos auch anschliessend per readingsBuldUpdate($hash,'pos',$newpos,1);
aktualisiert werden, damit der ausgewählte Menüeintrag auch beim nächsten Screenrefresh wieder angezeigt wird.
Ich bin mir da nicht mehr so sicher, müsste die alte Versionen wieder aus dem Archiv holen, aber "pos" war die auf 10er-Schritte gerundete Version und "position" die exakte Position.
Das der state jetzt "50" statt "pos 50" enthält, ist für mich nicht weiter störend, man muss halt die Definition für das devStateIcon anpassen, scheint aber zumindest bei einem User wieder zur Reaktion geführt zu haben: Geht nicht, muss update abwarten, statt mal ein wenig mitzudenken,.
Sollte man ev. gem. Code vielleicht mal beschreiben, dass state
open,10,20...closed als Werte annehmen kann.
Jezt höre ich auf, da zerfliesse, Büro ist unterm Dach...
Elektrolurch
Hallo Elektrolurch,
ok, jetzt habe ich mehr verstanden.
Der Teil mit dem Ergebnis von set ... ? war ja weiterhin enthalten, allerdings steht es am Anfang der set Routine und bei mir erzeugt fhemweb auch entsprechende Controls.
Was fehlte ist die Möglichkeit mit setList zu übersteuern, die habe ich mal in meinem Repository hinzugefügt und las pull request an Thomas weitergeschickt. Wenn Du testen willst: https://github.com/viegener/somfy-rts-fhem (https://github.com/viegener/somfy-rts-fhem)
Die Änderung das Reading von position auf pos zu ändern möchte ich so erstmal nicht machen, denn das würde sicher bei anderen Nutzern, die sich auf position verlassen (inklusive mir) zu Problemen führen. Vielleicht könnte man den Namen konfigurierbar machen (oder zumindest zentral im Kopf definiert)?
Gruss,
Johannes
Hallo Johannes,
mit der Ergänzung um setList war ein Wunsch eines Nutzers, der seine Markise über einen slider steuern wollte. Vermutlich gibt es da noch eine zweite Variante mit widgetOverwrite, aber da habe ich noch ad hoc kein Programmierbeispiel gefunden, wie das in einem Modul mit einzubauen ist oder ob überhaupt?
Mein Workaround:
in der Somfy_updateState habe ich an den zwei Stellen, an denen readingsBulkUpdate($hash,'position'...
aufgerufen wird, einfach das um
readingsBulkUpdate($hash,'pos'..
ergänzt und gut war.
Zitat:
Die Änderung das Reading von position auf pos zu ändern möchte ich so erstmal nicht machen, denn das würde sicher bei anderen Nutzern, die sich auf position verlassen (inklusive mir) zu Problemen führen. Vielleicht könnte man den Namen konfigurierbar machen (oder zumindest zentral im Kopf definiert)?
Der Workaround löst das... s.o.
Übrigens: Das mit den sich aktualisierenden Icons während des Verfahrens der Rollos ist natürlich sehr "effektvoll" und überzeugt auch den letzten Gegner von Hausautomatisierung!!!! :-)
Da der Aufwand für so was durchaus überschaubar ist ( a bisserl InternalTimer...) überlege ich schon, was man noch so blinken lassen könnte....
Gruß
Elektrolurch
ZitatVermutlich gibt es da noch eine zweite Variante mit widgetOverwrite, aber da habe ich noch ad hoc kein Programmierbeispiel gefunden, wie das in einem Modul mit einzubauen ist oder ob überhaupt?
Fuer widgetOverride braucht man im Modul nichts zu tun, siehe http://fhem.de/commandref.html#widgetOverride
Zitat:
Fuer widgetOverride braucht man im Modul nichts zu tun, siehe http://fhem.de/commandref.html#widgetOverride
Stimmt. Habe es gerade ausprobiert. Hatte es aber schon mal an dem Somfy getestet und da ging es nicht. Vielleicht hatte ich mich allerdings auch vertipp:
widgetOverwrite -> widgetOverride (Screenreader machts ungefähr gleich)
@Johannes: Die Ergänzung mit setList ist damit an für sich überflüssig.
Vielleicht die zwei Zeilen mit readingsBulkdUpdate($hash,'pos'...
einfügen, damit die Versionen nicht wieder auseinander laufen.. :-D
Elektrolurch
Hi,
ich habe nun einige Tage mit der V1.6 rumprobiert.
Mein System ist seit dem ich die 1.6 drauf habe sehr oft abgeschmiert.
Im Log ist mir dann folgendes aufgefallen:
SOMFY_set: handled command on --> move :on: newState :10:
Illegal division by zero at ./FHEM/10_SOMFY.pm line 1104.
Diese Meldung ist die letzte die vor einem Absturz im Log steht.
Komischer Weise passier der Crash nicht bei jedem Fahrbefehl. Dieser kam zustande als meine Rolladen gestern Abend runter fahren sollten.
Dies passiert über eine Structure mit einem async delay von 3 sek. Dies habe ich eingefügt weil sich mein NanoCul ab und zu mal aufhängt wenn er alle Somfys gleichzeitig besenden soll. Keine Ahnung woran das liegt, aber mit dem Delay funktionierte es seit langem.
Nun habe ich wieder die 1.5 eingespielt, und alles ist gut.
Die letzte Version die probiert hatte war die seit Gesten morgen eingeckeckte.
Schade, ich war guter Dinge das es nun alles mit der 1.6 funktioniert. Vielen Dank auch an dieser Stelle für den tollen support.
Kann bitte mal jemand nachforschen warum das Modul mein Fhem immer killt.
--Skusi
Das hatte ich gestern auch.
Ursache ist, dass
drive-down-time-to-100 und drive-down-time-to-close
den gleichen Wert haben, dann ergibt die Differenz 0.
Das passiert, wenn über die Position 100 hinaus gefahren wird, also von Sperrposition auf geschlossen.
Wir müssen das noch fixen, ich habe gestern abend auf die schnelle (es war zu heiß)
eine Abfrage auf gleiche Werte eingebaut und gebe eine FEhlermeldung aus.
Aber das muss noch korrekt berechnet werden.
Elektrolurch
Zitat von: Elektrolurch am 03 Juli 2015, 17:51:15
Ursache ist, dass
drive-down-time-to-100 und drive-down-time-to-close
den gleichen Wert haben, dann ergibt die Differenz 0.
Das passiert, wenn über die Position 100 hinaus gefahren wird, also von Sperrposition auf geschlossen.
Aua und ich kann nicht mal sagen es war zu heiss, den Code habe ich ja schon vor Wochen geschrieben.
Ich schaue mir das an.
Die Änderung mit setList könnte man drin lassen, da sie vielleicht andere verwenden wollen?
pos und position finde ich an sich nicht schön, ich würe das lieber über ein Attribut schaltbar machen:
additiionalPosReading <name of additional attribut for pos reading>
OK,
ich hab eben mal alle Zeiten neu gestoppt und die drive-to-100 eine skunde kleiner als die to-down gesetzt.
Dann per Update das aktuelle Somfy Modul installiert.
Erste Tests liefen super. Mal sehen ob das System nun auch morgen noch stabil bleibt.
Das mit den to-100 und to-close Zeiten habe ich nie richtig begriffen. Warum muß man diese unterschiedlichen Positionen angeben. Meine Rolladen sind doch zu wenn sie zu sind. Welche Position soll denn die to-100 sein ?
Die Lüftungsposition mache ich über die go-my Position.
Egal, cool das ich nun die 1.6 wieder testen kann...
--Skusi
Zitat von: Elektrolurch am 03 Juli 2015, 17:51:15
Ursache ist, dass
drive-down-time-to-100 und drive-down-time-to-close
den gleichen Wert haben, dann ergibt die Differenz 0.
Zur Erklärung: Die Zeiten sind so gedacht, dass die Position 100 den Zustand bei Rolläden beschreibt, wenn der Rolladen zwar bis unten gefahren ist, aber noch nicht vollständig gesperrt. Close ist der Zustand wenn wirklich alles komplett geschlossen ist. Insofern ist drive-down-time-to-100 kleiner als drive-down-time-to-close. Ausserdem ist üblicherweise drive-up-time-to-100 relativ klein und drive-up-time-to-open sogar noch grösser.
Die relativ komplexe Neuberechnung der Position basiert auf genau diesen Annahmen und Voraussetzungen.
Eigentlich hatte ich den Fall den Ihr beschreibt ja vorgesehen, allerdings ist die Bedingung etwas strikt. Im Falle das drive-down-time-to-100 und drive-down-time-to-close den gleichen Wert haben müsste eigentlich drive_up-time-to-100 den Wert 0 haben, denn das ist ja die umgekehrte Bewegung. Dann müsste die entsprechende Bedingung eigentlich zutreffen. Also könntet Ihr diesen Wert mal auf 0 setzen und schauen ob die Meldung dann auch bei Euch weg ist?
Ich werde das aber trotzdem noch anpassen,
Johannes
Also ich habe nochmals ein paar Änderungn vorgenommen:
- timing-Attribute werden auf konsistente Werte überprüft ansonsten wird eine Log-nachricht geniert und die timing daten werden ignoriert!
- Keine Division durch 0 und Vermeidung anderer perl Warnings
- Neues Attribut um weiteres pos reading zu ermöglichen additionalPosReading
Anbei eine aktualisiert Fassung und natürlich auch in github...
Rückmeldungen von tests sind willkommen,
Johannes
ist setList hier wirklich sinnvoll?
einem modul eine andere kommando liste unterzuschieben auf die es nicht vorbereitet ist führt doch nur zu Problemen. und für die ursprüngliche anfrage einen slider zu konfigurieren ist es nicht nötig. dafür gibt es einen fhem weiten mechanismus der für alle module gleich und automatisch vorhanden ist.
gruss
andre
Das Thema setList oder nicht überlasse ich den erfahrenen Entwicklern. Ich benötige es nicht und verstehe auch die Argumente von Andre es nicht zu unterstützen. Also wenn es gewünscht wird kann ich das gerne rausnehmen.
Ich habe aber noch einige Änderungen wg. der Fehlermeldungen und Abstürze (division durch 0) entfernt.
Bei der zweiten testrunde heute nachmittag habe ich dann noch eine Kokrrektur für den Fall position = 100 und befehl down gemacht.
Bis auf die letzte Korrektur sind meine pull requests auch schon von Thomas in sein Repository übernommen worden und werden wohl dann auch demnächst über update verfügbar sein.
Johannes
Zitat von: viegener am 04 Juli 2015, 19:10:56
Bis auf die letzte Korrektur sind meine pull requests auch schon von Thomas in sein Repository übernommen worden und werden wohl dann auch demnächst über update verfügbar sein.
Hallo Johannes,
ich habe gerade auch deinen letzten Pull Request akzeptiert und lade nachher die neue Version ins FHEM-Repository.
Grüße,
Thomas
Hallo Thomas und Johannes,
so a bisserl was habe ich noch gefunden:
1. Das mit dem zusätzlichen reading per Attribut (pos) funktioniert. Das einzige, was meiner Meinung nach fehlt, ist das Update für den Bildschirm. Ich habe da eine Auswahlliste, die set roll pos <Wert> genäeriert und somit auf das reading "pos" gebunden wird.
Wird eine Position über das Menü eingestellt, fährt der Roll auch da hin, aber der Wert der Liste wird nicht per longpoll aktualisiert. Baut man den Screen neu auf, dann steht der Wert der neuen Position korrekt drin.
In der Routine SOMFY_UpdateState wird
readingsBulkUpdate($hash,$addtlPosReading,$rounded) if ( defined($addtlPosReading) );
ohne den DoTrigger-Wert aufgerufen.
Am Schluss steht zwar:
readingsEndUpdate($hash,$doTrigger);
Ich habe das aber so verstanden, dass nur jene Werte dann per longpoll aktualisiert werden, die auch beim readingsBulkUpdate mit DoTrigger = 1 gesetzt wurden. Ev. irre ich auch.
2. Mit setList bin ich auch "meinungslos", da ja widgetOverride nun funktioniert und das set - Commando ja für "set roll pos <Wert>" ja schon von Hause aus eine Auswahlliste anbietet.
3. Es gibt da wohl noch ein Berechnungsproblem für die Fahrtzeiten, da wird 10.6 Sekunden berechnet, der stop - Befehl kommt aber erst nach 13 Sekunden (zwei Rolls wurden verfahren).
Und in einem Fall bekomme ich eine stop-Zeit von 6000 / 3000 s.
Außerdem sieht es so aus, dass ein Positionierungsbefehl, der eine Position enthält, auf der der Roll bereits steht, dazu führt, dass ein "stop" Befehl (also gomy) gesendet wird.
Hier die Details:
Heute morgen hatte ich folgende Situation: Vier Rolls auf der Ostseite standen auf "pos 100". Um 8:12 Uhr hat sich der Sonnenschutz aktiviert, da es auf der Fassade schon über 28 Grad war. Sonnenschutz heißt, dass die Rolls auf "pos 80" gefahren werden.
Für einen einzelnen Rolladen funktioniert das auch einwandfrei, wenn alle auf "offen" stehen, funktionierte das auch (mit meiner "privaten" Version, nun habe ich ja die aus fhem wieder eingespielt).
Die Beschattungssteuerung gibt vier Befehle hintereinander aus:
set roll1 Sonnenschutz
set roll2 Sonnenschutz
..
Sonnenschutz ist per eventMap "pos 80".
Alle vier Rolls hätten also nur ein kurzes Stück von pos 100 auf pos 80 fahren sollen, also Up und kurz darauf stop.
die meisten Rolls sind aber auf offen gefahren, also auf pos 0, so als wäre der "stop" Befehl ausgeblieben.
Frage: Die Timer für die Fahrtzeit werden doch schon rolladenweise, und nicht global verwaltet?
Normalerweise für die Rolladenautomatik verfahre ich die Rollos einzeln im Abstand von 10 Sekunden.
Die Beschattungssteuerung setzt die Fahrbefehle direkt hintereinander ab. Nicht das dadurch ein timing-Problem entsteht.
Ok. Nun doch getestet: :-)
Situation:
Zwei Rolladen von offen auf pos 80 gefahren.
set (Az|Bd)_FRolladen Sonnenschutz
Der erste fährt korrekt an die pos, der zweite schließt ganz.
Daten:
2015.07.05 10:42:50 4: SOMFY_set: Az_FRolladen -> entering with mode :send: cmd :pos: arg1 :80: pos :0:
2015.07.05 10:42:50 3: SOMFY_set: handled command pos --> move :on: newState :0:
2015.07.05 10:42:50 4: SOMFY_sendCommand: Az_FRolladen -> cmd :on:
2015.07.05 10:42:50 4: SOMFY_set: Az_FRolladen -> stopping in 10.64 sec
2015.07.05 10:42:50 4: SOMFY_set: Bd_FRolladen -> entering with mode :send: cmd :pos: arg1 :80: pos :0:
2015.07.05 10:42:50 3: SOMFY_set: handled command pos --> move :on: newState :0:
2015.07.05 10:42:50 4: SOMFY_sendCommand: Bd_FRolladen -> cmd :on:
2015.07.05 10:42:50 4: SOMFY_set: Bd_FRolladen -> stopping in 10.64 sec
2015.07.05 10:42:52 4: SOMFY Az_FRolladen on
2015.07.05 10:42:52 4: SOMFY Bd_FRolladen on
2015.07.05 10:42:53 4: SOMFY_TimedUpdate
2015.07.05 10:42:54 4: SOMFY_TimedUpdate: Az_FRolladen -> stopping in 7.62 sec
2015.07.05 10:42:54 4: SOMFY_TimedUpdate
2015.07.05 10:42:54 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 7.3 sec
2015.07.05 10:42:57 4: SOMFY_TimedUpdate
2015.07.05 10:42:57 4: SOMFY_TimedUpdate: Az_FRolladen -> stopping in 4.27 sec
2015.07.05 10:42:57 4: SOMFY_TimedUpdate
2015.07.05 10:42:57 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 3.83 sec
2015.07.05 10:43:00 4: SOMFY_TimedUpdate
2015.07.05 10:43:00 4: SOMFY_TimedUpdate: Az_FRolladen -> stopping in 0.810000000000001 sec
2015.07.05 10:43:00 4: SOMFY_TimedUpdate
2015.07.05 10:43:01 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 0.520000000000001 sec
2015.07.05 10:43:01 4: SOMFY_TimedUpdate
2015.07.05 10:43:01 4: SOMFY_sendCommand: Az_FRolladen -> cmd :stop:
2015.07.05 10:43:02 4: SOMFY_TimedUpdate
2015.07.05 10:43:02 4: SOMFY_sendCommand: Bd_FRolladen -> cmd :stop:
2015.07.05 10:43:02 4: SOMFY Az_FRolladen stop
2015.07.05 10:43:03 4: SOMFY Bd_FRolladen stop
Hier die Auffälligkeit:
2015.07.05 10:42:50 4: SOMFY_set: Bd_FRolladen -> stopping in 10.64 sec
2015.07.05 10:43:03 4: SOMFY Bd_FRolladen stop
Differenz: 13 Sekunden, statt berechnete 10.6 s.
Daher ist der zweite Roll auch ganz zu.
Nun habe ich beide auf "geschlossen" (pos 200) gefahren und dann mit
set (Az|Bd)_FRolladen Sonnenschutz
auf erneut auf pos 80 gefahren (Diesmal also in Gegenrichtung).
Der Az-Rolladen ist ganz aufgefahren, der Bd hat diesmal die richtige Position erreicht.
Hier das log:
2015.07.05 11:11:22 4: SOMFY_set: Az_FRolladen -> entering with mode :send: cmd :pos: arg1 :80: pos :200:
2015.07.05 11:11:22 3: SOMFY_set: handled command pos --> move :off: newState :200:
2015.07.05 11:11:22 4: SOMFY_sendCommand: Az_FRolladen -> cmd :off:
2015.07.05 11:11:22 4: SOMFY_set: Az_FRolladen -> stopping in 6.078 sec
2015.07.05 11:11:22 4: SOMFY_set: Bd_FRolladen -> entering with mode :send: cmd :pos: arg1 :80: pos :200:
2015.07.05 11:11:22 3: SOMFY_set: handled command pos --> move :off: newState :200:
2015.07.05 11:11:22 4: SOMFY_sendCommand: Bd_FRolladen -> cmd :off:
2015.07.05 11:11:22 4: SOMFY_set: Bd_FRolladen -> stopping in 5.15 sec
2015.07.05 11:11:24 4: SOMFY Az_FRolladen off
2015.07.05 11:11:24 4: SOMFY Bd_FRolladen off
2015.07.05 11:11:25 4: SOMFY_TimedUpdate
2015.07.05 11:11:26 4: SOMFY_TimedUpdate: Az_FRolladen -> stopping in 3.048 sec
2015.07.05 11:11:26 4: SOMFY_TimedUpdate
2015.07.05 11:11:26 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 1.77 sec
2015.07.05 11:11:28 4: SOMFY_TimedUpdate
2015.07.05 11:11:28 4: SOMFY_sendCommand: Bd_FRolladen -> cmd :stop:
2015.07.05 11:11:29 4: SOMFY_TimedUpdate
2015.07.05 11:11:29 4: SOMFY_sendCommand: Az_FRolladen -> cmd :stop:
2015.07.05 11:11:29 4: SOMFY Bd_FRolladen stop
2015.07.05 11:11:30 4: SOMFY Az_FRolladen stop
Die Zeile:
2015.07.05 11:11:22 4: SOMFY_set: Az_FRolladen -> stopping in 6.078 sec
und dann:
2015.07.05 11:11:26 4: SOMFY_TimedUpdate: Az_FRolladen -> stopping in 3.048 sec
ist merkwürdig, aber am Schluß wäre ja der korrekte stop-Befehl doch gesendet worden, trotzdem furh das Az-Rollo ganz auf.
Hier die drive-Werte für Az:
drive-down-time-to-100 13.3
drive-down-time-to-close 16.9
drive-up-time-to-100 3.18
drive-up-time-to-open 17.67
und der etwas schnellere Bd (obwohl baugleich)
drive-down-time-to-100 13.3
drive-down-time-to-close 15.75
drive-up-time-to-100 2.3
drive-up-time-to-open 16.55
Ich habe überprüft: Beide Rolls haben den STATE 80
Wenn ich aber jetzt erneut:
set (Az@BD)_FRolladen Sonnenschutz
eingebe, sollte ja eigentlich nichts passieren. Aber: Der Bd bleibt auch auf "Sonnenschutz", der Az (mit STATE 80, aber von eben noch auf offen) fährt los und schliesst ganz.
Beide haben aber den STATE 80 weiterhin.
Hier das log dazu:
2015.07.05 11:22:39 4: SOMFY_set: Az_FRolladen -> entering with mode :send: cmd :pos: arg1 :80: pos :80:
2015.07.05 11:22:39 3: SOMFY_set: handled command pos --> move :stop: newState :80:
2015.07.05 11:22:39 4: SOMFY_sendCommand: Az_FRolladen -> cmd :stop:
2015.07.05 11:22:40 4: SOMFY Az_FRolladen stop
Das schaut für mich so aus, als wäre da noch der timer mit
2015.07.05 11:11:22 4: SOMFY_set: Az_FRolladen -> stopping in 6.078 sec
aktiv gewesen und daher wurde dast stop-Commando gesendet.
Gruß und noch schönes Schwitzen
Elektrolurch
Zitat von: Elektrolurch am 05 Juli 2015, 10:37:15
1. Das mit dem zusätzlichen reading per Attribut (pos) funktioniert. Das einzige, was meiner Meinung nach fehlt, ist das Update für den Bildschirm. Ich habe da eine Auswahlliste, die set roll pos <Wert> genäeriert und somit auf das reading "pos" gebunden wird.
Wird eine Position über das Menü eingestellt, fährt der Roll auch da hin, aber der Wert der Liste wird nicht per longpoll aktualisiert.
Baut man den Screen neu auf, dann steht der Wert der neuen Position korrekt drin.
In der Routine SOMFY_UpdateState wird
readingsBulkUpdate($hash,$addtlPosReading,$rounded) if ( defined($addtlPosReading) );
ohne den DoTrigger-Wert aufgerufen.
Am Schluss steht zwar:
readingsEndUpdate($hash,$doTrigger);
Ich habe das aber so verstanden, dass nur jene Werte dann per longpoll aktualisiert werden, die auch beim readingsBulkUpdate mit DoTrigger = 1 gesetzt wurden. Ev. irre ich auch.
Das longpoll-Verhlaten muss ich mal bei mir überprüfen.
Soweit ich readingsBulkUpdate richtig gelesen habe, wird dochanged (also der letzte Parameter) automatisch gesetzt wenn er nicht explizit übergeben wird. Deshalb werden ja alle BulkUpdates ohne changed parameter aufgerufen.
Zitat von: Elektrolurch am 05 Juli 2015, 10:37:15
2. Mit setList bin ich auch "meinungslos", da ja widgetOverride nun funktioniert und das set - Commando ja für "set roll pos <Wert>" ja schon von Hause aus eine Auswahlliste anbietet.
OK wenn ich in den nächsten Tagen keine andere Meinung höre, kann ich das auch wieder entfernen.
Zitat von: Elektrolurch am 05 Juli 2015, 10:37:15
3. Heute morgen hatte ich folgende Situation: Vier Rolls auf der Ostseite standen auf "pos 100". Um 8:12 Uhr hat sich der Sonnenschutz aktiviert, da es auf der Fassade schon über 28 Grad war. Sonnenschutz heißt, dass die Rolls auf "pos 80" gefahren werden.
Für einen einzelnen Rolladen funktioniert das auch einwandfrei, wenn alle auf "offen" stehen, funktionierte das auch.
Die Beschattungssteuerung gibt vier Befehle hintereinander aus:
set roll1 Sonnenschutz
set roll2 Sonnenschutz
..
Sonnenschutz ist per eventMap "pos 80".
Alle vier Rolls hätten also nur ein kurzes Stück von pos 100 auf pos 80 fahren sollen, also Up und kurz darauf stop.
Alle vier Rolls sind aber auf offen gefahren, also auf pos 0, so als wäre der "stop" Befehl ausgeblieben.
Muss das ganze noch Mal nachstellen mit verbose 4.
Frage: Die Timer für die Fahrtzeit werden doch schon rolladenweise, und nicht global verwaltet?
Normalerweise für die Rolladenautomatik verfahre ich die Rollos einzeln im Abstand von 10 Sekunden.
Die Beschattungssteuerung setzt die Fahrbefehle direkt hintereinander ab. Nicht das dadurch ein timing-Problem entsteht.
Das sollte ich auch bei mir nachstellen können, allerdings werden die Timer soweit ich das verstehe schon über den hash auseinandergesteuert.
Meinem Verständnis nach erzeugt ja jeder InternalTimer aufruf einen separaten Timer, nur beim RemoveInternalTimer wird anhand des übergebenen Arguments der richtige Timer ausgewählt. Da als arg $hash übergeben wird sollten eigentlich unterschiedliche Timer angestossen werden.
Hallo Johannes,
sorry, die Hitze war doch noch nicht so groß, so dass ich das mal im Detail nachgestellt habe und meinen Beitrag mit den Daten und einer Zusammenfassung der Ergebnisse "angereichert" habe. Ich hoffe, das das weiter hilft.
Ich bekomme teils sehr große Werte für den stop-Befehl.... -> siehe oben.
Elektrolurch
OK, ich muss dass mal in mehreren Abschnitten abhandeln:
Zuerst mal die einfach Erklärung:
Zitat von: Elektrolurch am 05 Juli 2015, 10:37:15
Wenn ich aber jetzt erneut:
set (Az@BD)_FRolladen Sonnenschutz
eingebe, sollte ja eigentlich nichts passieren. Aber: Der Bd bleibt auch auf "Sonnenschutz", der Az (mit STATE 80, aber von eben noch auf offen) fährt los und schliesst ganz.
Beide haben aber den STATE 80 weiterhin.
Hier das log dazu:
2015.07.05 11:22:39 4: SOMFY_set: Az_FRolladen -> entering with mode :send: cmd :pos: arg1 :80: pos :80:
2015.07.05 11:22:39 3: SOMFY_set: handled command pos --> move :stop: newState :80:
2015.07.05 11:22:39 4: SOMFY_sendCommand: Az_FRolladen -> cmd :stop:
2015.07.05 11:22:40 4: SOMFY Az_FRolladen stop
Das schaut für mich so aus, als wäre da noch der timer mit
2015.07.05 11:11:22 4: SOMFY_set: Az_FRolladen -> stopping in 6.078 sec
aktiv gewesen und daher wurde dast stop-Commando gesendet.
Der Log ist erwartungsgemäss und basiert NICHT auf dem alten Timer: Wenn eine pos Angabe (hier pos 80) kommt und die Berechnung feststellt, dass nichts zu tun ist, also keine Zeit für die Bewegung notwendig ist, wird einfach ein Stop-Komando gesendet (da ja keine Bewegung erfolgen soll).
Und der nächste Teil:
Zitat von: Elektrolurch am 05 Juli 2015, 10:37:15
Hier die Auffälligkeit:
2015.07.05 10:42:50 4: SOMFY_set: Bd_FRolladen -> stopping in 10.64 sec
2015.07.05 10:43:03 4: SOMFY Bd_FRolladen stop
Differenz: 13 Sekunden, statt berechnete 10.6 s.
Daher ist der zweite Roll auch ganz zu.
Ja, das ist in der Tat schlecht, über 20% Abweichung in der Zeit ist ein Problem. In meinen Logfiles gibt es Abweichungen von ungefähr 2% (zum Teil sogar nahe Null) in aboluten Werten ist das delta zwischen 0.02 und 0.05s.
Eine Möglichkeit wo ein Delta passieren kann ist zwischen Aufruf der update routine und neustarten des timers, denn dazwischen werden Readings aufgefrischt und damit kann (inbesondere bei vielen abhängigen Aktionen) einiges an Zeit vergehen.
Dieses Delta kann man verringern, in dem man den neuen Zeitstempel bereits am Anfang berechnet. Ich habe mal eine Somfy-Version zum Ausprobieren angehängt, kannst Du die mal speziell für diese Zeitdifferenz laufen lassen?
Bei mir ist damit das Delta auf 0 gegangen (also wenn alle drei sekunden aufgefrischt werden soll, wird auch nach genau 3.00 Sekunden neu berechnet).
Das beinhaltet aber keine Änderung für das Problem mit mehreren Bewegungen gleichzeitig,
Johannes
Zitat von: Elektrolurch am 05 Juli 2015, 10:37:15
Nun habe ich beide auf "geschlossen" (pos 200) gefahren und dann mit
set (Az|Bd)_FRolladen Sonnenschutz
auf erneut auf pos 80 gefahren (Diesmal also in Gegenrichtung).
Der Az-Rolladen ist ganz aufgefahren, der Bd hat diesmal die richtige Position erreicht.
OK, das Szenario habe ich bei mir jetzt mal mit mehreren Kombinationen durchgespielt und kann Dein Problem nicht nachstellen. Allerdings ist ja auch in Deinem Log erkennbar, dass entsprechend Stop-Befehle gesendet werden.
Die Vermutung ist also, dass möglicherweise diese Befehle durch Funk überlagert werden, oder aus anderen Gründen nicht empfangen werden. Bei mir ist ein CUL433 nur für Somfy-senden zuständig in einem Holzhaus und da habe ich einen Rolladen im Dachgeschoss, der etwa jeden 10. Befehl nicht empfängt (bzw. nicht darauf reagiert).
Wenn das nicht die Ursache ist, müssten wir schauen, ob es andere gibt, die ebenfalls solche Probleme bei mehreren Rolladenbewegungen haben.
Hallo Johannes,
Zitat:
Wenn eine pos Angabe (hier pos 80) kommt und die Berechnung feststellt, dass nichts zu tun ist, also keine Zeit für die Bewegung notwendig ist, wird einfach ein Stop-Komando gesendet
Wird das tatsächlich gesendet? Denn bei stehendem Rollo fährt das Stop-Kommando ja in die gespeicherte (mygo) - Position.
So einen Effekt hatte ich, wenn die drive-Attribute nicht korrekt sind und der Rolo schon oben oder unten ansteht und dann das "stop" kommt. Dann fährt er halt auf die gespeicherte Position.
stop sollte man also auf keinen Fall senden, wenn der Rollo schon an der gewünschten Positionsteht.
Ich hatte da ursprünglich in ser set-Routine ein return mit Ext, wenn die Position schon angefahren wurde und erneut angefahren werden sollte.
Die neue Version habe ich reloaded. Hier wieder das log für
set (Az|Bd)_FRolladen Sonnenschutz
Log
2015.07.05 15:20:02 4: SOMFY_set: Az_FRolladen -> entering with mode :send: cmd :pos: arg1 :80: pos :0:
2015.07.05 15:20:02 3: SOMFY_set: handled command pos --> move :on: newState :0:
2015.07.05 15:20:02 4: SOMFY_sendCommand: Az_FRolladen -> cmd :on:
2015.07.05 15:20:02 4: SOMFY_set: Az_FRolladen -> stopping in 10.64 sec
2015.07.05 15:20:02 4: SOMFY_set: Bd_FRolladen -> entering with mode :send: cmd :pos: arg1 :80: pos :0:
2015.07.05 15:20:02 3: SOMFY_set: handled command pos --> move :on: newState :0:
2015.07.05 15:20:02 4: SOMFY_sendCommand: Bd_FRolladen -> cmd :on:
2015.07.05 15:20:02 4: SOMFY_set: Bd_FRolladen -> stopping in 10.64 sec
2015.07.05 15:20:03 4: SOMFY Az_FRolladen on
2015.07.05 15:20:04 4: SOMFY Bd_FRolladen on
2015.07.05 15:20:05 4: SOMFY_TimedUpdate
2015.07.05 15:20:05 4: SOMFY_TimedUpdate: Az_FRolladen -> stopping in 7.62 sec
2015.07.05 15:20:05 4: SOMFY_TimedUpdate
2015.07.05 15:20:05 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 7.29 sec
2015.07.05 15:20:08 4: SOMFY_TimedUpdate
2015.07.05 15:20:08 4: SOMFY_TimedUpdate: Az_FRolladen -> stopping in 4.62 sec
2015.07.05 15:20:08 4: SOMFY_TimedUpdate
2015.07.05 15:20:08 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 4.29 sec
2015.07.05 15:20:11 4: SOMFY_TimedUpdate
2015.07.05 15:20:11 4: SOMFY_TimedUpdate: Az_FRolladen -> stopping in 1.62 sec
2015.07.05 15:20:11 4: SOMFY_TimedUpdate
2015.07.05 15:20:12 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 1.21 sec
2015.07.05 15:20:12 4: SOMFY_TimedUpdate
2015.07.05 15:20:12 4: SOMFY_sendCommand: Az_FRolladen -> cmd :stop:
2015.07.05 15:20:13 4: SOMFY_TimedUpdate
2015.07.05 15:20:13 4: SOMFY_sendCommand: Bd_FRolladen -> cmd :stop:
2015.07.05 15:20:13 4: SOMFY Az_FRolladen stop
2015.07.05 15:20:14 4: SOMFY Bd_FRolladen stop
Immer noch 12, statt 10.6 Sekunden.
Nun nur set Bd_FRolladen Sonnenschutz
2015.07.05 15:32:38 4: SOMFY Bd_FRolladen on
2015.07.05 15:32:39 4: SOMFY_TimedUpdate
2015.07.05 15:32:39 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 7.63 sec
2015.07.05 15:32:42 4: SOMFY_TimedUpdate
2015.07.05 15:32:42 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 4.63 sec
2015.07.05 15:32:45 4: SOMFY_TimedUpdate
2015.07.05 15:32:45 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 1.63 sec
2015.07.05 15:32:47 4: SOMFY_TimedUpdate
2015.07.05 15:32:47 4: SOMFY_sendCommand: Bd_FRolladen -> cmd :stop:
2015.07.05 15:32:48 4: SOMFY Bd_FRolladen stop
Wenn ich nur einen Roll verfahre, wird die Position exakt angefahren. Jetzt steht der Bd genau da, wo er soll.
Ich kann mir allerdings kaum vorstelllen, wo fhem bei zwei Rolos seine Zeit verschwendet, dass kann doch kaum in die Sekunden gehen...!?
Mir ist im übringe aufgefallen, dass in EXACT auch nur die gerundeten Werte stehen. Das spielt zwar nur dann eine Rolle, wenn man häufig positioniert und zwischen drin nicht auf die Endpositionen fährt.
Zur Berechnung: Ich hatte das so gemacht, dass nach Ablaufen der Zeit die Routine die tatsächlich vergangene Zeit benutzt und die Startzeit davon abzieht. Die Start- und Endezeiten habe ich genau kurz vor dem 'Senden des Somfy-Befehls ermittelt.
Zitat:
Die Vermutung ist also, dass möglicherweise diese Befehle durch Funk überlagert werden, oder aus anderen Gründen nicht empfangen werden. Bei mir ist ein CUL433 nur für Somfy-senden zuständig in einem Holzhaus und da habe ich einen Rolladen im Dachgeschoss, der etwa jeden 10. Befehl nicht
Dachte ich auch daran. Nun "wissenschaftlich" ausgetestet. Mehrfach wiederholt, warte jetzt drauf, dass die Nachbarn die Polizei geholt haben :-)
Den Az_Roll kann ich von geschlossen auf Sonnenschutz fahren, klappt immer, wenn ich nur ihn verfahre.
Führe ich aber den Befehl immer gleichzeitig für zwei Rollos aus, dann bleibt der Az-Roll nicht bei Sonnenschutz stehen, sondern fährt auf offen.
Gemäß log würden die Sendebefehle ja wie folgt abgearbeitet:
Az -> offen
Bd -> offen
Az -> stop (Roll reagiert nicht, fährt auf offen)
Bd -> stop bleibt bei pos 80 stehen.
100 % reproduzierbar bei 5 Versuchen (ich höre schon das Tatütata.. :-)).
Der Az und Bd - Stop Befehl liegen sendetechnisch relativ dicht beieinander, aber eigentlich sollte das ja einem CUL egal sein, da der das Timing managed und m.K.n. gibt es zwischen jedem Sendebefehl eine Pause von 200 ms.
Hier noch mal das log:
2015.07.05 15:44:03 4: SOMFY_set: Az_FRolladen -> entering with mode :send: cmd :pos: arg1 :80: pos :200:
2015.07.05 15:44:03 3: SOMFY_set: handled command pos --> move :off: newState :200:
2015.07.05 15:44:03 4: SOMFY_sendCommand: Az_FRolladen -> cmd :off:
2015.07.05 15:44:03 4: SOMFY_set: Az_FRolladen -> stopping in 6.078 sec
2015.07.05 15:44:03 4: SOMFY_set: Bd_FRolladen -> entering with mode :send: cmd :pos: arg1 :80: pos :200:
2015.07.05 15:44:03 3: SOMFY_set: handled command pos --> move :off: newState :200:
2015.07.05 15:44:03 4: SOMFY_sendCommand: Bd_FRolladen -> cmd :off:
2015.07.05 15:44:03 4: SOMFY_set: Bd_FRolladen -> stopping in 5.15 sec
2015.07.05 15:44:04 4: SOMFY Az_FRolladen off
2015.07.05 15:44:05 4: SOMFY Bd_FRolladen off
2015.07.05 15:44:06 4: SOMFY_TimedUpdate
2015.07.05 15:44:06 4: SOMFY_TimedUpdate: Az_FRolladen -> stopping in 3.058 sec
2015.07.05 15:44:06 4: SOMFY_TimedUpdate
2015.07.05 15:44:06 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 1.79 sec
2015.07.05 15:44:08 4: SOMFY_TimedUpdate
2015.07.05 15:44:08 4: SOMFY_sendCommand: Bd_FRolladen -> cmd :stop:
2015.07.05 15:44:09 4: SOMFY_TimedUpdate
2015.07.05 15:44:09 4: SOMFY_sendCommand: Az_FRolladen -> cmd :stop:
2015.07.05 15:44:09 4: SOMFY Bd_FRolladen stop
2015.07.05 15:44:10 4: SOMFY Az_FRolladen stop
Was mich aber verunsichert, sind die angegebenen Fahrzeiten für die Rollos, bei dem Bd sieht das ja plausibel aus, beim dem Az aber überhaupt nicht.
Oder ist die Log-Ausgabe nicht plausibel?
2015.07.05 15:44:06 4: SOMFY_TimedUpdate: Az_FRolladen -> stopping in 3.058 sec
2015.07.05 15:44:06 4: SOMFY_TimedUpdate
2015.07.05 15:44:06 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 1.79 sec
Das sind doch berechnete Zeiten, die nach Ablauf etwas tun sollen, also beim Az weit in der Zukunft liegen für das Stop...?
Elektrolurch
Zusammenfassung für den eiligen Leser
- Timing hat sich auch bei Elektrolurch durch meine Änderung siehe neues Somfy deutlich verbessert, ich schicke mal einen pull-request auf die Reise
- my-position / zusätzlich Stop hat wohl noch ein Problem, das bei mir nicht auftritt, da ich keine my-pos verwenden
- Vermutung meinerseits es gibt vielleicht ein Problem mit dem Senden, wenn Befehle sehr kurz hintereinander auftreten, hier müsste jemand mit CULFW know how helfen
Zitat von: Elektrolurch am 05 Juli 2015, 16:11:41
Zitat:
Wenn eine pos Angabe (hier pos 80) kommt und die Berechnung feststellt, dass nichts zu tun ist, also keine Zeit für die Bewegung notwendig ist, wird einfach ein Stop-Komando gesendet
Wird das tatsächlich gesendet? Denn bei stehendem Rollo fährt das Stop-Kommando ja in die gespeicherte (mygo) - Position.
So einen Effekt hatte ich, wenn die drive-Attribute nicht korrekt sind und der Rolo schon oben oder unten ansteht und dann das "stop" kommt. Dann fährt er halt auf die gespeicherte Position.
stop sollte man also auf keinen Fall senden, wenn der Rollo schon an der gewünschten Positionsteht.
Ich hatte da ursprünglich in der set-Routine ein return mit Ext, wenn die Position schon angefahren wurde und erneut angefahren werden sollte.
Ok, das ist neu für mich, da ich keine my-pos mehr an den Rolläden benutze. Soweit ich das verstanden hatte gibt es zwei verschiedene Kommandos 11 my-pos und 10 für stop. Also wenn Du über fhemweb ein Stop sendest bewegt sich der Rolladen zur my-pos, kannst Du das verifizieren? Es wäre sicher möglich das stop Kommando auszubauen.
Zitat von: Elektrolurch am 05 Juli 2015, 16:11:41
2015.07.05 15:20:02 4: SOMFY_sendCommand: Az_FRolladen -> cmd :on:
2015.07.05 15:20:02 4: SOMFY_set: Az_FRolladen -> stopping in 10.64 sec
2015.07.05 15:20:02 4: SOMFY_sendCommand: Bd_FRolladen -> cmd :on:
2015.07.05 15:20:02 4: SOMFY_set: Bd_FRolladen -> stopping in 10.64 sec
2015.07.05 15:20:12 4: SOMFY_sendCommand: Az_FRolladen -> cmd :stop:
2015.07.05 15:20:13 4: SOMFY_sendCommand: Bd_FRolladen -> cmd :stop:
Immer noch 12, statt 10.6 Sekunden.
Nein, wenn Du das Log genau anschaust, ist das Problem weg. Es läuft von :02 bis :12 bzw. :02 bis :13 also passend für die 10.64 sec
Das scheint also auch bei Dir Verbesserung zu bringen.
Zitat von: Elektrolurch am 05 Juli 2015, 16:11:41
Mir ist im übringe aufgefallen, dass in EXACT auch nur die gerundeten Werte stehen. Das spielt zwar nur dann eine Rolle, wenn man häufig positioniert und zwischen drin nicht auf die Endpositionen fährt.
EXACT wird auch etwas gerundet, soweit ich weiss auf ganze Zahlen (oder ganze Zahlen). Ich wollte da keine Genauigkeit verwende, die so durch Zeitabläufe nicht erreichbar ist. Ich hatte mal bei unbelastetem System mal Serien gemacht 0-70-100-70-0-... und dabei waren jeweils an der Position 70 Fluktuation um die 10cm herausgekommen, die hatte ich für tolerabel gehalten, da sie sich bei mir nicht aufgeschaukelt hatten.
Zitat von: Elektrolurch am 05 Juli 2015, 16:11:41
Zur Berechnung: Ich hatte das so gemacht, dass nach Ablaufen der Zeit die Routine die tatsächlich vergangene Zeit benutzt und die Startzeit davon abzieht. Die Start- und Endezeiten habe ich genau kurz vor dem 'Senden des Somfy-Befehls ermittelt.
So ähnlich wurde das auch gemacht, das Problem war, das sich die berechnete nächste Laufzeit auch auf den selben Zeitstempel bezog, aber nach dem BulkUpdate ein neuer Zeitstempel verwendet wurde. Es wurden also von da ab 3 Sek laufen gelassen und nicht 3 Sekunden seit der Berechnung (wie gesagt, das scheint ja jetzt bei Dir auch zu funktionieren).
Zitat von: Elektrolurch am 05 Juli 2015, 16:11:41
Dachte ich auch daran. Nun "wissenschaftlich" ausgetestet. Mehrfach wiederholt, warte jetzt drauf, dass die Nachbarn die Polizei geholt haben :-)
Den Az_Roll kann ich von geschlossen auf Sonnenschutz fahren, klappt immer, wenn ich nur ihn verfahre.
Führe ich aber den Befehl immer gleichzeitig für zwei Rollos aus, dann bleibt der Az-Roll nicht bei Sonnenschutz stehen, sondern fährt auf offen.
Gemäß log würden die Sendebefehle ja wie folgt abgearbeitet:
Az -> offen
Bd -> offen
Az -> stop (Roll reagiert nicht, fährt auf offen)
Bd -> stop bleibt bei pos 80 stehen.
100 % reproduzierbar bei 5 Versuchen (ich höre schon das Tatütata.. :-)).
Der Az und Bd - Stop Befehl liegen sendetechnisch relativ dicht beieinander, aber eigentlich sollte das ja einem CUL egal sein, da der das Timing managed und m.K.n. gibt es zwischen jedem Sendebefehl eine Pause von 200 ms.
Hier bin ich überfragt, das klingt wirklich nicht nach Funkübedeckung, da immer dasselbe Kommando fehlt. Da bräuchten wir jetzt HIlfe von den CULFW-Leuten, bzw. Thomas, der das ja meines Wissens für die CULFW implementiert hat. Was verwendest Du denn als Sender CUL433 oder CUL868 und läuft da noch was anderes drauf? Welche Repetition hast Du eingestellt, kannst Du die mal runtersetzen?
Zitat von: Elektrolurch am 05 Juli 2015, 16:11:41
Was mich aber verunsichert, sind die angegebenen Fahrzeiten für die Rollos, bei dem Bd sieht das ja plausibel aus, beim dem Az aber überhaupt nicht.
Oder ist die Log-Ausgabe nicht plausibel?
2015.07.05 15:44:06 4: SOMFY_TimedUpdate: Az_FRolladen -> stopping in 3.058 sec
2015.07.05 15:44:06 4: SOMFY_TimedUpdate
2015.07.05 15:44:06 4: SOMFY_TimedUpdate: Bd_FRolladen -> stopping in 1.79 sec
Das sind doch berechnete Zeiten, die nach Ablauf etwas tun sollen, also beim Az weit in der Zukunft liegen für das Stop...?
Sorry das Problem verstehe ich nicht.
Von pos 200 nach 80 heisst Fahrzeit von 200 nach 100 und dann noch bis 80
Fahrzeit von 200 nach 100 --> bei AZ 3.18 und
plus Fahrzeit von 100 nach 80 also --> (100-80)/100 * (17.67-3.18) = 2.898
macht 6.07...
Also stimmt die Berechnung und auch Nachkommastellen werden herangezogen, das hatte ich ursprünglich gar nicht getestet ;D
Gruss,
Johannes
Hallo Johannes,
ja, das ist so
set Roll stop
verfährt den Roll auf die gespeicherte Position.
Zitat:
Sorry das Problem verstehe ich nicht.
Von pos 200 nach 80 heisst Fahrzeit von 200 nach 100 und dann noch bis 80
Fahrzeit von 200 nach 100 --> bei AZ 3.18 und
plus Fahrzeit von 100 nach 80 also --> (100-80)/100 * (17.67-3.18) = 2.898
macht 6.07...
Also stimmt die Berechnung und auch Nachkommastellen werden herangezogen, das hatte ich ursprünglich gar nicht getestet ;D
Sorry. Das ist mein Screenreader, der macht aus 6.010 sechstausendzehn, aus 6.12 sechskommazwölf.
Da habe ich mich ins Boxhorn jagen lassen.
Ich könnte mir einen Work-around bauen:
Nicht direkt das fhem - Kommando absetzen, sondern das über eine sub machen, die die Kommandos sammelt und dann im Abstand von 10 s sendet.
Damit wäre das Problem umgangen, leider aber nicht verstanden :-)
Elektrolurch
Wenn das Zeitintervall bekannt wäre, in dem Befehle zu KOnflikten führen, könnte man natürlich auch eine entsprechende Verzögerung einführen indem Vor dem Senden auf Zeitablauf gewartet wird.
Nachteil: die exakte Positionierung geht dann natürlich verloren.
Das mit dem zusätzlichen stop-Befehl sollte ich also auch ausbauen, allerdings nehme ich an, das könnte an mehreren Stellen passiern. Das muss ich wohl heute abend mal anschauen.
Zitat von: Elektrolurch am 05 Juli 2015, 16:11:41
Der Az und Bd - Stop Befehl liegen sendetechnisch relativ dicht beieinander, aber eigentlich sollte das ja einem CUL egal sein, da der das Timing managed und m.K.n. gibt es zwischen jedem Sendebefehl eine Pause von 200 ms.
Ich habe mal grob durchgeschaut in der culfw, es sieht nicht so aus, als ob eine Pause von 200ms bei Somfy-Kommandos in der CULFW vorkommt. Allerdings ist das Protokoll ansonsten vollständig d.h. es gib auch die Pause zwischen zwei Befehlen.
Interessant ist, dass bei Dir ja genau der Stop-Befehl Az, der kurz nach dem Stop von Bd gesendet wird. Das Spricht für die Vermutung, dass der zweite Befehl aus irgendeinem Grund nicht durchkommt, wenn kurz davor ein anderer Befehl gesendet wurde.
Damit wäre eine zentrale Pause im Somfy-Modul vielleicht wirklich eine Lösung, allerdings habe ich noch keine einfache Idee gehabt, wie man das implementieren könnte ohne aufwändige Queue- oder Timer-Verwaltung
Zitat von: viegener am 06 Juli 2015, 22:43:16
Interessant ist, dass bei Dir ja genau der Stop-Befehl Az, der kurz nach dem Stop von Bd gesendet wird. Das Spricht für die Vermutung, dass der zweite Befehl aus irgendeinem Grund nicht durchkommt, wenn kurz davor ein anderer Befehl gesendet wurde.
Damit wäre eine zentrale Pause im Somfy-Modul vielleicht wirklich eine Lösung, allerdings habe ich noch keine einfache Idee gehabt, wie man das implementieren könnte ohne aufwändige Queue- oder Timer-Verwaltung
Ich habe mal durchgerechnet, bei Standardmässig 6 wiederholungen dauert das Senden eines Somfy-komandos etwa 300ms. Dazu kommen noch Übertragungen, Umschaltzeiten und die anderen CUL-Kommandos, die jeweils vorher gesendet werden, das kann eng werden. Allerdings erklärt das für mich die Probleme nicht.
Zitat von: Elektrolurch am 06 Juli 2015, 11:35:05
Hallo Johannes,
ja, das ist so
set Roll stop
verfährt den Roll auf die gespeicherte Position.
@elektrolurch : Anbei ist eine aktualisierte Version, die kein Stop mehr schicken sollte, kannst Du die mal ausprobieren?
Danke,
Johannes
@Johannes: Danke für deine Bemühungen! Ich habe gerade leider zu wenig Zeit, um mich richtig um das Somfy-Modul zu kümmern.
Kurz zum Verhalten: Die Ingenieure bei Somfy waren so schlau, Stop und Go-My auf den gleichen Funkbefehl zu legen, d.h. schicke ich "stop" an einen Rolladen, der schon steht, geht der auf die "my" Position.
Ich habe intern im Modul 2 Befehle daraus gemacht (10 und 11), um zu unterscheiden, was der User geschickt hat.
Zum Protokoll: ein Frame ist ca. 80ms lang + 30ms Pause, also 110ms. Macht bei 6 Wiederholungen 660ms, das merkt man schon deutlich.
Der Code in der CULFW macht allerdings den HW-Sync zu kurz, vielleicht ist das ein Problem, wenn die Kommandos schnell hintereinander kommen.
Am Wochenende habe ich Zeit und kann mit meinen Rollos (und den Frame-Zeiten) spielen, vielleicht kann ich das auch hier nachstellen.
Grüße,
Thomas
Hallo,
habe jetzt erst einmal einen kleinen Workaround gebastelt:
Die Aurfrufe der Somfy-Befehle laufen über eine sub. Das hatte ich immer schon so, denn darin wird geprüft, ob noch jemand auf der Terrasse ist und das Rollo wird später heruntergefahren, wenn keiner mehr draussen ist.
Insofern war es dann einfach, die restlichen direkten Somfy-Aufrufe (der Beschattungssteuerung) auszubauen und auch über diese sub zu leiten.
Die schreibt die Befehle in ein array und startet einen internen Timer, der den Puffer alle 10 Sekunden um einen Befehl leert.
Damit ist das Problem des Sendetimings erst einmal umgangen und die Rollos fahren auch wieder genau dahin, wo sie auch sollen.
Das mit dem stop-Befehl ist solange ein Problem, solange man nicht genau weiß, wo der Rolladen exakt steht. Wird er z.B. über eine FB verfahren, so weiß fhem ja nichts davon. Soll dann über die Kombi aus moveup(oder down) und stop eine genaue Position angefahren werden, kann das dann schon mal schief gehen. Der Rollo erreicht vor dem stop-Befehl eine Endposition. Kommt dann der stop, so fährt der Rollo auf die go-my Position.
Auf die Weise habe ich mit besagter Terrassentür schon einige Sprints einlegen müssen, um mich nicht auszusperren.
Elektrolurch
Zitat von: Elektrolurch am 08 Juli 2015, 11:59:17
Das mit dem stop-Befehl ist solange ein Problem, solange man nicht genau weiß, wo der Rolladen exakt steht. Wird er z.B. über eine FB verfahren, so weiß fhem ja nichts davon. Soll dann über die Kombi aus moveup(oder down) und stop eine genaue Position angefahren werden, kann das dann schon mal schief gehen. Der Rollo erreicht vor dem stop-Befehl eine Endposition. Kommt dann der stop, so fährt der Rollo auf die go-my Position.
Auf die Weise habe ich mit besagter Terrassentür schon einige Sprints einlegen müssen, um mich nicht auszusperren.
Elektrolurch
OK, eine generelle Lösung Pausen zwischen den Befehlen zu erreichen werde ich jetzt erstmal nicht angehen. Wenn ich das richtig verstehe, befindet sich Deine sub ausserhalb des 10_Somfy-Moduls?
Den zusätzlichen Stop-Befehl habe ich ausgebaut (Version oben), gibt es dazu Erfahrungswerte?
Das mit der zusätzlichen manuellen Bedienung durch eine Fernbedienung habe ich bei mir durch einen fhemduino gelöst, der diese Befehle empfängt und auch als Somfy-Modul weitergibt. Dadurch wird die Positionierung auch im Falle der manuellen Bedienung korrekt. Bei mir geht es sogar, dass ich in fhem von ganz offen auf Pos 50 fahren lasse und frühzeitig stop auf der manuellen FB drücke sodass der Rolladen stoppt und die Position in fhem korrekt aktualisiert wird (z.B: bei 30). Das ist bei uns auch nötig, da immer noch mehr als die Hälfte der Befehle über die Fernbedienungen erfolgt.
Johannes
Zitat von: viegener am 08 Juli 2015, 15:45:48
Das mit der zusätzlichen manuellen Bedienung durch eine Fernbedienung habe ich bei mir durch einen fhemduino gelöst, der diese Befehle empfängt und auch als Somfy-Modul weitergibt. Dadurch wird die Positionierung auch im Falle der manuellen Bedienung korrekt.
Das klingt gut, leider gibt es in der CULFW noch keinen Somfy-Empfang.
Kann man den Code vom fhemduino dafür nutzen?
Ich hab damals nur Senden eingebaut, weil das leichter umzusetzen war...
Hallo,
ich denke, gemeint ist http://forum.fhem.de/index.php/topic,34793.msg298549.html#msg298549 (http://forum.fhem.de/index.php/topic,34793.msg298549.html#msg298549)
Gruß, Thomas
Zitat von: tomatic am 08 Juli 2015, 17:25:01
Hallo,
ich denke, gemeint ist http://forum.fhem.de/index.php/topic,34793.msg298549.html#msg298549 (http://forum.fhem.de/index.php/topic,34793.msg298549.html#msg298549)
Gruß, Thomas
Hi Thomas,
das habe ich auch so verstanden :-)
Schön wäre aber, wenn jemand (z.B. ich) die CULFW erweitert, und auch den Empfang von Somfy-Befehlen implementiert.
Im Somfy-Modul muss dann nur noch die Adresse der Original-Fernbedienung hinterlegt werden (analog zum fhemduino), dann funktioniert die Positionierung hier auch.
Zitat von: thdankert am 08 Juli 2015, 17:44:50
Hi Thomas,
das habe ich auch so verstanden :-)
Schön wäre aber, wenn jemand (z.B. ich) die CULFW erweitert, und auch den Empfang von Somfy-Befehlen implementiert.
Im Somfy-Modul muss dann nur noch die Adresse der Original-Fernbedienung hinterlegt werden (analog zum fhemduino), dann funktioniert die Positionierung hier auch.
Ich habe mich nicht wirklich in die culfw-Entwicklung eingelesen, da aber beides auf dem AVR läuft (einmal ARDUINO-code für fhemduino und einmal AVR/gcc toolchain) und das Empfangen relativ einfach zu implementieren war, sollte es möglich sein. Bisher war die Einstiegshürde für mich zu hoch, da ich auf die schnelle keine Anleitung gefunden habe welche Werkzeuge/Versionen für ein Erzeugen der culfw (geht das unter Windows?) nötig sind. Die fhemduino-Variante ist ja relativ kostengünstig (HW ~ 10 €) und bringt bei mir auch noch weitere Protokolle.
Also mal die Frage:
- Wieviel Interesse gibt es?
- Passt das noch in den Speicher bei der CUL ?
Gruss,
Johannes
@thdankert
Ja, stimmt natürlich, hatte deinen Beitrag falsch verstanden. :$
Das Senden des Stop-Befehls bei gleicher (bereits erreichter) Position scheint jetzt ausgebaut zu sein.
Das mit dem Timing habe ich ja erst einmal mit dem Work-Around gelöst, ist also nicht so vordringlich. Sollte jemand noch damit ein Problem haben, muss man sich halt noch daran errinnern, was möglicherweise die Ursache ist.
Nein, die su habe ich natürlich nichts ins Modul übernommen, da sind ja einige Spezifika (Terrassentür usw) drin, die ja vmtl. nicht von allgemeinem Interesse sein sollten.
Alles was mit Beschattung, Wochentagsprogrammierung usw gibt, ist in einem eigenenen 99_mUtilsRolladen.pm verstaut worden.
An dem Empfang der FB-Signale wäre ich schon interessiert, nobody is perfect, my name is nobody.
Also sollte die Hausautomatisierung schon ein möglichst exaktes Abbild des Ist-Zustandes wiedergeben. :-)
Schon alleine wegen WAF... :-D
Elektrolurch
Zitat von: viegener am 08 Juli 2015, 18:00:32
Also mal die Frage:
- Wieviel Interesse gibt es?
- Passt das noch in den Speicher bei der CUL ?
*Interesse anmeld* :-)
Ob es noch reinpasst, kann ich leider nicht beantworten.
Kompilieren geht am einfachsten unter Linux, die AVR/gcc Toolchain gibt es aber auch für Windows.
Ich fand den Code der CULFW nicht so übersichtlich, Senden ging noch ziemlich einfach einzubauen.
Aber Empfang müsste z.B. mit in rf_receive.c eingebaut werden (da werden alle im Modus "SlowRF" empfangenen Daten dekodiert),
und das war mir beim schnell drüber schauen zu unaufgeräumt :-)
@CULFW-Entwickler: Bitte korrigiert mich, wenn ich Unsinn schreibe, und es eine viel einfachere Möglichkeit gibt.
Wir könnten natürlich auch einen neuen RFMode erstellen (SomfyRTS), und dann die Interrupt-Methode von fhemduino fast 1:1 übernehmen.
Aber das hat den Nachteil, dass dann keine anderen Daten mehr empfangen werden (der CUL wäre dann exklusiv für Somfy, analog zu HomeMatic).
Ich unterstütze gern, wenn jemand eine Dokumentation hat, wie die CULFW grob aufgebaut ist.
Grüße,
Thomas
Zitat@CULFW-Entwickler: Bitte korrigiert mich, wenn ich Unsinn schreibe, und es eine viel einfachere Möglichkeit gibt.
Die Beobachtung ist korrekt, liegt daran, dass jeder nur sein Sempf dazupackt, und den Rest nur mit sptzen Zange anfasst.
Einen Maintainer wie in FHEM gibt es nicht.
Evtl. ist das bei dem vom Bjoern aktiver betreuten a-culfw besser.
Ich habe heute abend nochmal ein paar Stabilisierungen eingechecked und auch als pull request überstellt.
Danke nochmals für die Rückmeldungen!!!
Kurze Beschreibung:
- Verbessertes Timing für die Positionsbestimmung wie oben mit Elektrolurch abgestimmt
- Stop-Kommando wird nur noch gesendet wenn wirklich eine Bewegung erfolgt (Ebenfalls Dank an Elktrolurch hier)
- go-my Kommando wurde wegen tippfehler (_ statt -) nicht korrekt behandelt (Rückmeldung von realkeule hier: http://forum.fhem.de/index.php/topic,24158.msg310848.html#msg310848 (http://forum.fhem.de/index.php/topic,24158.msg310848.html#msg310848)
- Verschiedene log-Meldungs korrekturen
Neue Version gibt es auch schon in github: http://forum.fhem.de/index.php/topic,24158.msg310848.html#msg310848 (http://forum.fhem.de/index.php/topic,24158.msg310848.html#msg310848)
Rückmeldung ist natürlich erwünscht,
Johannes
Zitat von: thdankert am 08 Juli 2015, 20:08:13
*Interesse anmeld* :-)
Ich fand den Code der CULFW nicht so übersichtlich, Senden ging noch ziemlich einfach einzubauen.
Aber Empfang müsste z.B. mit in rf_receive.c eingebaut werden (da werden alle im Modus "SlowRF" empfangenen Daten dekodiert),
und das war mir beim schnell drüber schauen zu unaufgeräumt :-)
OK, ich werde mich mal anfangen einzuarbeiten (entweder a-culfw oder culfw). Gibt es eigentlich Pläne die beiden Varianten zusammenzuführen?
Einen getrennten Empfangsmode fände ich nicht gut, denn dann bräuchte man wenn ncoh andere 433Mhz-protokolle bedient werden sollen einen zusätzlichen CUL433. Viele haben vermutlich wie ich auch noch andere 433Mhz_Protokolle im Einsatz. Statt einem zusätzlichen CUL kann man auch gleich einen fhemduino dazuhängen und wir hätten nichts gewonnen.
Ich muss mir dazu aber erst noch einen zusätzlichen cul bauen, da meine beiden vorhandenen busware culs im Produktiveinsatz sind. Achso und leider ich ich auch erstmal 2 Wochen geschäftlich unterwegs :-[
Zitat von: viegener am 09 Juli 2015, 01:40:18
Neue Version gibt es auch schon in github: http://forum.fhem.de/index.php/topic,24158.msg310848.html#msg310848 (http://forum.fhem.de/index.php/topic,24158.msg310848.html#msg310848)
Hallo Johannes,
sieht gut aus, bei mir habe ich keine Fehler entdeckt.
Stop wird jetzt nur noch geschickt, wenn sich die Position geändert hat, sehr schön!
Ich habe den pull request akzeptiert und die Änderungen auch gerade ins FHEM-Repository eingecheckt.
Gibts wie immer ab morgen als update.
Grüße und danke,
Thomas
Hallo zusammen,
ich habe gestern zufällig gesehen, dass es mitlerweile ein Modul zur Ansteuerung der Somfy-Geräte gibt ;D und habe meinen FHEM-Server direkt umgestellt. (Bisher hatte ich mit einem HM-LC-Sw4-Ba-PCB die Fernbedienung gesteuert.)
Die Steuerung funktioniert soweit tadellos. Hier einmal ein herzliches Dankeschön an die Entwickler!!!
Einzig im Logfile erscheinen bei jedem Schaltvorgang merkwürdige Fehlermeldungen:
2015.07.09 06:58:38 3: SOMFY_set: handled command on --> move :on: newState :0:
2015.07.09 06:58:38 3: SOMFY_set: handled command on --> move :on: newState :0:
2015.07.09 06:58:39 3: CUL_0: Unknown code YsA74A0057010000, help me!
2015.07.09 06:58:40 3: CUL_0: Unknown code YsAE4F003E020000, help me!
2015.07.09 06:58:42 3: SOMFY_set: handled command off --> move :off: newState :100:
2015.07.09 06:58:42 3: SOMFY_set: handled command off --> move :off: newState :100:
2015.07.09 06:58:43 3: CUL_0: Unknown code YsA82C0058010000, help me!
2015.07.09 06:58:43 3: CUL_0: Unknown code YsAF29003F020000, help me!
Kann mir jemand sagen, womit das zusammenhängt, bzw. was ich falsch gemacht habe?
Gruß,
neo28
Zitat von: neo_28 am 09 Juli 2015, 09:57:16
2015.07.09 06:58:39 3: CUL_0: Unknown code YsA74A0057010000, help me!
2015.07.09 06:58:40 3: CUL_0: Unknown code YsAE4F003E020000, help me!
2015.07.09 06:58:43 3: CUL_0: Unknown code YsA82C0058010000, help me!
2015.07.09 06:58:43 3: CUL_0: Unknown code YsAF29003F020000, help me!
Hallo neo_28,
das kann passieren, wenn nur das SOMFY-Modul zu FHEM hinzugefügt wurde, aber der Rest nicht aktualisiert wurde.
Du kannst ein FHEM update machen, dann sollten die Meldungen auch wieder verschwinden.
Grüße,
Thomas
Ok....
Ich hatte aber nicht speziell das SOMFY-Modul hinzugefügt...
Ich gehe immer über die Update Funktion.
Mache trotzdem gerade nochmal ein Update.
Indego 1200 connect
Zitat von: bjoern.konstanti am 09 Juli 2015, 10:04:44
Ich gehe immer über die Update Funktion.
Mache trotzdem gerade nochmal ein Update.
Bist du der gleiche Nutzer wie neo_28?
Es könnte auch sein, dass deine CULFW zu alt ist, ich hatte (letztes Jahr Oktober?) noch eine Änderung am SOMFY-Support gemacht.
Eine Bitte: das hier ist der Entwickler-Thread, normale Fragen bitte in den "User"-Thread einstellen: http://forum.fhem.de/index.php/topic,24158.540.html (http://forum.fhem.de/index.php/topic,24158.540.html)
Sorry, war falsch angemeldet...
Danke für den Hinweis zum User - Thread melde mich da wieder
Indego 1200 connect
Ich habe mich nochmal mit dem Thema "go-my" befasst und habe anbei mal eine Testversion angehängt.
Was ist enthalten:
- Es gibt eine neues Attribute my-position, in dem man die numerische Position für go-my in fhem hinterlegen kann
- wenn die Timer-Attribute gesetzt sind, wird der Inhalt von my-position verwendet um zu berechnen wie langer der Rolladen wohl brauchen wird bis er my-pos erreicht hat - state ist stop aber position ist dann korrekt
- ohne timer-attribute müsste es sogar einen state go-my geben
@Elektrolurch, realkeule: Vielleicht könntet Ihr das mal ausprobieren?
Ich habe nachwievor keinen meiner Rolladen mit einer my-pos versehen und wollte das auch nicht, weil es ganz praktisch ist, wenn man beliebig oft Stop senden kann ohne, dass sich nachts um 2 noch ein lauter Rolladen bewegt ;D
eben erst gesehen. ich werde es die woche testen und mich melden.
danke :)
bernd
Hallo, ich spiele mit dem Gedanken, meine manuell bedienbaren Rolläden mit Somfy RTS Motoren nachzurüsten.
Natürlich mit dem Hintergedanken, die Steuerung über FHEM und dieses Modul zu realisieren. Da der "Fred" seit fast einem Jahr tot ist, habe ich mich gefragt, was aus den letzten Verbesserungen von viegener passiert ist (My Position). Funktioniert diese Erweiterung?
Hallo defdanny,
das SOMFY-Modul funktioniert, ich bin nicht mehr der Maintainer, das hat viegener dankenswerter weise übernommen!
Der Thread sieht nur tot aus, weil es keine großen Weiterentwicklungen mehr gibt - es ist halt eine Rolladensteuerung, da sind die Möglichkeiten irgendwann erschöpft :-)
Ich bin mir gerade nicht sicher, ob die numerische "my-position" mit drin ist, aber abgesehen davon lassen sich die Rolläden komplett über FHEM steuern.
"My" lässt sich ebenfalls anfahren, wenn es im Motor gespeichert wurde (z.B. mit der normalen Fernbedienung).
Es gibt von Somfy mittlerweile mehrere Motorgenerationen, es ist wichtig, dass du Somfy RTS nimmst, nicht die neuen mit io-homecontrol.
Grüße,
Thomas
Zitat von: defdanny am 07 Juni 2016, 22:49:23
Hallo, ich spiele mit dem Gedanken, meine manuell bedienbaren Rolläden mit Somfy RTS Motoren nachzurüsten.
Natürlich mit dem Hintergedanken, die Steuerung über FHEM und dieses Modul zu realisieren. Da der "Fred" seit fast einem Jahr tot ist, habe ich mich gefragt, was aus den letzten Verbesserungen von viegener passiert ist (My Position). Funktioniert diese Erweiterung?
Die Änderungen, die ich letztes Jahr vorgenommen habe sind alle von Thomas übernommen und in der aktuellen Version enthalten.
Man kann die my-pos anfahren (allerdings weiss fhem dann nicht wo der Rolladen dann steht, denn die Information steckt nur im Rolladen)
Man kann über pos <zahl> eine fast beliebige Position anfahren und hierbei verwendet das Somfy-Modul die Laufzeiten der Rolläden, die man einmalig als Attribute angibt. Dann kann man aber auch von pos70 auf pos 30 fahren und fhem sendet die richtige Richtung und auch den Stop-befehl
Es gibt zwar Dinge, die man noch umbauen/anbauen kann, aber momentan geht es eher um die Anbindung vom signalduino als weiteren Sender (und Empfänger).
@viegener, @thedankert: Besten Dank für eure gar nicht "leblosen" Antworten. ;)
Ich werde berichten, sobald die Anbindung der SOMFY Rolläden voran geht.
Ich habe Rolläden mit Somfy-RTS, die habe ich bisher mit dem RFXTRX433E über das Modul TRX-Light angesteuert.
Da ich auch einen nanoCUL433 betreibe habe ich vom RFXTRX433E auf CUL und dem SOMFY-Modul umgestellt.
Auf dem freigewordenen Steckplatz betreibe ich den FhemDuino zum Somfy-Empfang der Handsender.
Mir reichen die von TRX_Light bekannten set-Befehle und Stati (up,down,stop,program).
Daher nutze ich auch nur die vergleichbaren Zustände und Befehle des SOMFY-Moduls ohne die Attribute "drive-.*".
Ich benutze die Attribute
eventMap off:up on:down
devStateIcon open:fts_shutter_down:down go-my:fts_shutter_manual:go-my closed:fts_shutter_up:up
webCmd up:down:go-myDas funktioniert so, wie ich es mir vorstelle.
Allerdings erhalte ich immer Warnungen beim Ausführen der set Befehle (up, down, go-my) im Log:
Zitat2016.06.22 07:14:35.016 1: PERL WARNING: Argument "closed" isn't numeric in addition (+) at ./FHEM/10_SOMFY.pm line 969, <GEN13> line 31.
Ich weiss, es sind nur Warnungen, sie kommen aus der Subroutine "SOMFY_RoundInternal". Da sie recht übersichtlich ist, habe ich durch Einfügen der Zeile
no warnings "all"; nach Zeile 967 für die Subroutine "SOMFY_RoundInternal" die Warnugen abgeschaltet.
Wäre es möglich, diese Änderung in die offizielle 10_SOMFY.pm zu übernehmen?
Edit: Wenn ein CUL Somfy empfangen könnte, würde ich mich freuen, sonst werde ich den Einbau in den SIGNALduino abwarten und damit den CUL und FHEMDuino ersetzen.
Hallo,
ich spiele auch mit dem Gedanken, die vorhandenen Simu-Rolladen per FHEM steuerbar zu machen.
Als Anfänger habe ich dazu eine Frage: Braucht man zwingend einen CUL oder reicht ein normales 433MHz-Sendemodul aus?
Vielen Dank für die Hilfe!
Also stand heute ist Senden mit dem CUL möglich und empfangen mit einem FHEMDuino.
Es wird an Unterstützung für beides im Signalduino gearbeitet.
CUL-Unterstützung für empfangen ist in Arbeit, es gab eine erste Laborversion, liegt aber momentan bei mir auf Eis, da ich im Sommer einfach nicht dazukomme.
Was Du mit ein "normales 433Mhz-Sendemodul" meinst ist mir aber nicht klar. Ich finde auch einen CUL-433 ziemlich normal :-)
Hallo, anbei ein kurzer Erfahrungsbericht:
Vor 4 Wochen hatte ich mir im EG drei Rolläden (2 x Terrassentür, 1 x großes Erkerfenster) mit SOMFY RTS Motoren nachrüsten lassen.
Nachdem die Motoren eingebaut waren und mit den Wand-Funktastern gekoppelt waren, wurde es spannend für mich: Würde das Anlernen der Funkmotoren an FHEM (über einen CUL433) ebenfalls so einfach über die Bühne gehen? Kurz und knapp: JA !
Wie in der commandref beschrieben, habe ich zunächst drei "devices" vom Typ "SOMFY" in FHEM angelegt.
Dann jeden Motor (nacheinander) in den Anlernmodus für neue Sender gesetzt und über die FHEM GUI den "set prog" Befehl des passenden "devices" ausgelöst.
Manuelles Hoch- und Runterfahren der Rolläden, sowie das Anfahren auf die bei SOMFY-Motoren integrierte Favoriten-Position ("my"-Position) funktionierten ab diesem Zeitpunkt problemlos. Nun fehlten noch die Laufzeiten für das komplette Herauf- und Herunterfahren der Rolläden, so wie optional die Laufzeiten zum Erreichen der "fast geschlossen"-Position (gibt es dafür einen Fachbegriff? Gemeint ist, dass sich der Rolladen bereits bis zum Boden bewegt hat, die Schlitze zwischen den Lamellen noch sichtbar sind). Diese mittels Stoppuhr-Funktion meines Smartphones erfasst und die so ermittelten Sekundenwerte in den passenden Attributen den "devices" eingetragen.
Trotz fehlenden Rückkanals vom Motor zu FHEM ist damit eine recht genaue Positionsbestimmung pro Rolladen möglich.
Nun noch schnell ein passendes "at"-Device erstellt, um ein zeitgesteuertes Hoch- und Runterfahren zum Sonnenaufgang und Sonnenuntergang zu ermöglichen - und ZACK, FEDDISCH - Rolladen-Steuerung steht! 8)
Damit das Ganze nun auch noch hübsch zu bedienen ist, bin ich den tollen Anregungen (hier aus dem Forum) zur Integration von Rolladensteuerungen in die TabletUI gefolgt.
Mit dem Ergebnis bin ich sehr zufrieden und möchte mich an dieser Stelle herzlichst bedanken bei all denjenigen, die bei der Entwicklung und Test des SOMFY-Moduls mitgewirkt haben!
Vielen Dank und gern geschehen.
Sehr schön aufgeräumte Oberfläche.
@defdanny:
Ich beschatte meinen Wintergarten ebenfalls mit 7 Somfy RTS Motoren. Zusätzlich zu den 7 Einzeldevices hab ich in FHEM noch das Somfy Device "Alle Jallousien" engelegt und auf allen Motoren eingelernt.
Das hat nicht nur den Vorteil, dass die gesamte Front mit einem Tastendruck hoch/runter gefahren werden kann. FHEM sendet somit auch nicht 7 Einzelbefehle sondern nur einen an alle Motoren gemeinsam. Ergo fahren alle Motoren gleichzeitig an.
By the way: pass auf dein "Statefile" bzw. deine "Rolling Codes" auf. Hatte den Fall, dass ich nach einem Crash alle Motoren neu pairen musst da die Rolling Codes verrutscht waren und ich keine aktuelle Sicherung des Statefiles hatte.
@scuba: danke dir für den tipp. Das "Alle Rolladen"-Device baue ich mir wohl noch. Wo finde ich das "Statefile"?
Zitat:
CUL-Unterstützung für empfangen ist in Arbeit, es gab eine erste Laborversion, liegt aber momentan bei mir auf Eis, da ich im Sommer einfach nicht dazukomme.
Ich bin schon ganz heiß drauf, da ich keinen weiteren USB-Port mehr frei habe... :-)
statefile: findest Du unter log(fhem.save
Tipp: Bau Dir ein "at" - Befehl, wie so z.B.
define fhem_save_at at *+02:00 save
Damit wird dann alle zwei Stunden alle states und readings in das log/fhem.save - File geschrieben. Damit sind dann auch alle Daten für die Somfys gesichert.
Elektrolurch
Hallo zusammen,
zunächst einmal ein riesengroßes Lob und ein Danke für die tolle Arbeit in diesem Modul. Ich konnte es ohne Probleme einrichten und funktioniert auch seit einigen Wochen hervorragend.
Nun möchte ich ein wenig "weiter basteln" und habe zwei Anliegen, zu denen ich im Forum bislang nichts finden konnte:
1.) Ich habe wie scuba mehrere Rolläden in ein neues Device gepackt, da mir der nanoCUL bei Gruppen > 3 (bei repitition = default) und > 5 (bei repitition = 2) abschmiert.
Zitat von: scuba am 25 Juli 2016, 16:28:01
Zusätzlich zu den 7 Einzeldevices hab ich in FHEM noch das Somfy Device "Alle Jallousien" engelegt und auf allen Motoren eingelernt.
Das hat nicht nur den Vorteil, dass die gesamte Front mit einem Tastendruck hoch/runter gefahren werden kann. FHEM sendet somit auch nicht 7 Einzelbefehle sondern nur einen an alle Motoren gemeinsam. Ergo fahren alle Motoren gleichzeitig an.
Diese Methode hat allerdings den Nachteil, dass in den Einzeldevices nicht der Status angepasst wird.
Ich habe fast alle Beiträge zu dem Modul durchforstet und habe auch in Post #670 in "Erweiterung CULFW um Somfy/Simu" gesehen, dass es mit externen Fernbedienungen geht, aber finde nichts dazu für einen "Sammeldevice" in Fhem selbst. Habe ich ggf. etwas überlesen?
2) Wenn ich die Rolladen auf "MY-Position" fahre, weiß FHEM ja nicht mehr den korrekten Status, da die Position bei den RTS-Motoren im Motor gespeichert ist.
Bestünde ggf. die Möglichkeit in Fhem einen Wert für die MY-Position festzulegen, damit Fhem auch die Position kennt?
Eine Einstellung könnte dann wie folgt laufen: Rolladen mit Fhem in die gewünschte Positions fahren und den Wert in Position ablesen und als Wert für die MY-Position hinterlegen. Mit der Somfy-Fernbedienung dann die My-Position festlegen.
Kommt jetzt per Fernbedienung oder aus FHEM der Befehl go-my und der Rolladen läuft ohne ein weiteres go-my zwecks stoppen in diese Postition, ist der Wert auch in FHEM hinterlegt.
Ich bin leider kein Programmierer und wüsste nicht wie ich das umsetzen könnte, stünde aber jederzeit gerne für Tests zur Verfügung.
Wenn die Themen hier im Entwicklungsthread nix zu suchen haben, mache ich auch gerne nochmals Einzelthemen auf.
Vielen Dank schonmals und viele Grüße
Thorsten
ZitatDiese Methode hat allerdings den Nachteil, dass in den Einzeldevices nicht der Status angepasst wird.
Hier könntest Du ein notify nutzen und mit setstate, setreading den Status der Einzelgeräte nachziehen.
Eventuell kannst Du auch das Attribut rawDevice nutzen.
ZitatWenn ich die Rolladen auf "MY-Position" fahre, weiß FHEM ja nicht mehr den korrekten Status, da die Position bei den RTS-Motoren im Motor gespeichert ist.
Bestünde ggf. die Möglichkeit in Fhem einen Wert für die MY-Position festzulegen, damit Fhem auch die Position kennt?
Auch hier könntest Du mit einem notify und mit setstate oder setreading die go-my Position setzen.
Die Fernbedienung wird z.Zt. nur vom SIGNALDuino oder FHEMduino empfangen.
Hallo Ellert,
vielen Dank für Deine schnelle Antwort.
Notify und setstate sind sicherlich eine machbare Lösung (werde ich mich mal mit auseinandersetzen).
Ich hätte bei den zusammengefassten Rollos nur gedacht, dass es analog des "rawdevices" Attributes im Modul 14_FHEMduino_SomfyR.pm auch möglich wäre den Status des Einzeldevices entsprechend der "Fahrzeit" des Sammeldevices anzupassen. Wenn ich das mit dem Notify richtig verstehe würde dann der Status vom Sammeldevice übernommen werden, der aber gar nicht wissen kann, in welcher Position der Einzeldevice zuvor war. (ich hoffe ich bin noch verständlich...)
Bislang habe ich noch keinen FHEMduino, aber werde mir den in kürze wohl noch zusammenbauen (es sei denn, die Entwicklung zum Empfangen der Somfy-Fernbedienungen über den nanoCUL ist in absehbarer Zeit abgeschlossen). Ist es dann so, dass der in FHEM angelegte Sammeldevice dann auch einmal als "Fernbedienung" angelegt werden kann und dann mit dem Attribut "rawdevices" die Verknüpfung zu den Einzeldevices hergestellt werden kann?
Viele Grüße
Thorsten
ZitatBislang habe ich noch keinen FHEMduino
Der SignalDuino (SD) kann Somfy senden und empfangen im Zusammenspiel mit dem SOMFY-Modul, es kommt darauf an, was Du mit dem nanoCul noch alles empfangen willst, der SD ggf. könnte den nanoCul 433 ersetzen, das spart einen USB-Port.
Ich nutze nur die Positionen open, closed und go-my, mehr halte ich bei einem Sammel-Device mit unterschiedlichen Laufzeiten von Einzelgeräten nicht sinnvoll. Diese eindeutigen Positionen kann man, wie beschrieben nachziehen. Aber bei bekannten Positionen der Einzelgeräte und deren Laufzeiten und der Position, Richtung und Laufzeit des Sammelgerätes sollte sich auch per notify die nächste Position der Einzelgeräte bestimmen und setzen lassen.
Ich verwende kein Sammel-Device, da ich die Rolläden zeitversetzt ansteuere und daher auch kein zusätzliches IO-Device benötige. Mit dem RFXTRX ist die gleichzeitige Ansteuerung kein Problem, er hängt sich auch nicht auf.
ZitatIst es dann so, dass der in FHEM angelegte Sammeldevice dann auch einmal als "Fernbedienung" angelegt werden kann und dann mit dem Attribut "rawdevices" die Verknüpfung zu den Einzeldevices hergestellt werden kann?
Da ich diese Konstellation nicht verwende, habe ich keine Erfahrungswerte, aber das Attribut ist ja dafür gemacht.
Zitat von: Ellert am 16 September 2016, 19:32:49
Der SignalDuino (SD) kann Somfy senden und empfangen im Zusammenspiel mit dem SOMFY-Modul,...
Das ist schon möglich :P ?
In den somfy threads steht davon gar nichts :(
Dann werde ich mir mal die Teile bestellen, dann bekommt der nanoCUL ein 868er Funkmodul, wollte demnächst eh mit Homematic starten.
Muss dann noch etwas beim flashen (spezielle Version) beachtet werden?
Abermals ein riesen Dankeschön
Zitat von: Grafkox am 16 September 2016, 14:52:00
2) Wenn ich die Rolladen auf "MY-Position" fahre, weiß FHEM ja nicht mehr den korrekten Status, da die Position bei den RTS-Motoren im Motor gespeichert ist.
Bestünde ggf. die Möglichkeit in Fhem einen Wert für die MY-Position festzulegen, damit Fhem auch die Position kennt?
Eine Einstellung könnte dann wie folgt laufen: Rolladen mit Fhem in die gewünschte Positions fahren und den Wert in Position ablesen und als Wert für die MY-Position hinterlegen. Mit der Somfy-Fernbedienung dann die My-Position festlegen.
Kommt jetzt per Fernbedienung oder aus FHEM der Befehl go-my und der Rolladen läuft ohne ein weiteres go-my zwecks stoppen in diese Postition, ist der Wert auch in FHEM hinterlegt.
Ich bin leider kein Programmierer und wüsste nicht wie ich das umsetzen könnte, stünde aber jederzeit gerne für Tests zur Verfügung.
Wenn die Themen hier im Entwicklungsthread nix zu suchen haben, mache ich auch gerne nochmals Einzelthemen auf.
Vielen Dank schonmals und viele Grüße
Thorsten
Leider ist das mit dem go-my bei den Rolläden nicht so einfach. Die Somfy-steuerungen unetrstützen zwei getrennte my-position, eine die von unten und eine die von oben angesteuert wird. Ausserdem ist das Funkkommando zum Ansteuern der my-pos dasselbe wie den Rolladen zu stoppen. Ob gestoppt wird, einer der beiden my-pos angefahren wird oder gar nichts erfordert das Wissen üebr Position und Info ob der Motor noch läuft oder nicht. Da dadurch zuviele mögliche Fehler auftreten können und eine Kenntnis der Position vorausgesetzt wird habe ich keine sinnvolle Möglichkeit gefunden das ins Somfy-modul einzubauen.
Ich glaube das steht auch schon irgendwo in diesem Thread
Zitat von: Grafkox am 16 September 2016, 21:27:57
Das ist schon möglich :P ?
In den somfy threads steht davon gar nichts :(
Dann werde ich mir mal die Teile bestellen, dann bekommt der nanoCUL ein 868er Funkmodul, wollte demnächst eh mit Homematic starten.
Muss dann noch etwas beim flashen (spezielle Version) beachtet werden?
Abermals ein riesen Dankeschön
Für den SD habe ich diese Version benutzt
update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r32-mcspecial/controls_signalduino.txtVon viegener gibt es eine angepasste SOMFY Version, den Link habe ich gerade nicht gefunden. Die vom mir benutzte Version habe ich angehängt.
Hallo Veigener,
auch dir danke für deine Antwort.
in #91 hattest du eine Testversion von 2015 mit wahrscheinlich genau dieser Funktion hinterlegt (hatte ich gerade noch beim Stöbern) gesehen. Ich zögere aber mit demeinem testen, da ich noch nicht so fit in fhem und einem evtl. Zurückdrehen bin. Werde aber morgen ein Backup machen und dann diese Version mal testen, oder sind da signifikante Neuerungen nicht mehr drin vorhanden?
@Ellert:
Danke für die Info. Werde die die erforderlichen Sachen bestellen und dann berichten.
Gruß
Thorsten
@grafkox: Ja die testversion habe ich nicht weiter verfolgt, weil es aus den obigen Gründen nicht wirklich konsistent zu bekommen ist. Die Testversion von damals berücksichtig zum Beispiel nicht, dass es unterschiedliche my-pos von unten und von oben geben kann.
Hallo Johannes,
ich bin inzwischen auch ein Stück weiter gekommen und habe inzwischen auch meinen Fhemduino zusammengebaut und auch die Wand- und Handsender angelernt und mit den Fhem-Devices verknüpft.
Wie versprochen habe ich mal mit der Version vom 06 August 2015 rumgetestet und konnte in Bezug auf die My-Pos keine segnifikanten Unterschiede (korrekte zeitnahme beim "drive-..-time-to-..." vorausgesetzt), ob ich die My-Position von unten oder oben anfahre (Meine Frau war vom Kreppband an den Tür- und Fensterrahmen "begeistert") feststellen.
Der Status wird auch wunschgemäß beim Ansteuern über Fhem übernommen.
Von daher würde ich es begrüßen, wenn die Funktion fest ins Modul übernommen werden könnte.
Wenn diese Funktion dann übernommen werden würde, könnte dann auch aus dem FHEMduino_SomfyR-Device der "Befehl 11" für go-my übergeben werden?
Vielleicht als Ansatz: wenn nicht innerhalb von x Sekunden der Befehl 20 oder 40 abgesetzt wurde und der Befehl 11 abgesetzt wird = Fahre go-my,
ansonsten bedeutet Befehl 11 = Stopp (bzw. analog dem normalen Modul-Verhalten).
Wenn zu guter Letzt dann noch die Möglichkeit bestünde "normale" Sofmy Devices mit rawDevice mit anderen Somfy Devices zu verknüpfen (Analog FHEMduino_SomfyR) wären auch viele Eventualitäten von Gruppen-Devices abgedeckt. (Ich denke das Problem habe sicherlich nicht nur ich)
Somit müsste man sich nicht mit Notifys und Setstates etc behelfen (habe es heute nach Einlesen und 3h probieren erstmal aufgegeben).
Stehe natürlich gerne auch für ausführlichste Tests zur Verfügung.
Viele Grüße
Thorsten
Zitat von: Grafkox am 03 Oktober 2016, 22:21:13
Wenn zu guter Letzt dann noch die Möglichkeit bestünde "normale" Sofmy Devices mit rawDevice mit anderen Somfy Devices zu verknüpfen (Analog FHEMduino_SomfyR) wären auch viele Eventualitäten von Gruppen-Devices abgedeckt. (Ich denke das Problem habe sicherlich nicht nur ich)
Das geht jetzt schon, denn Du kannst Doch auch ein FHEMduino_SomfyR device anlegen für andere Somfy-Devices. Damit lassen sich auch rawDevices für normale FHEM Somfy-Devices anlegen.
Hallo Johannes und danke für die schnelle Antwort.
Hatte ich absolut nicht auf dem Schirm für den Somfy Device einen HEMduino_SomfyR device anzulegen.
Habe ich gerade bereits eingebaut und funktioniert wie gewünscht.
Wie siehst du die anderen beiden Punkte?
Hallo,
Zitat:
Der SignalDuino (SD) kann Somfy senden und empfangen
Dann werde ich mir mal die Teile bestellen, dann bekommt der nanoCUL ein 868er Funkmodul,
Frage:
Entweder suche ich falsch, aber wo gibt es das Teil zu bestellen und was brauche ich da noch? Ist das viel Bastelarbeit (mit Löten?)...
Gruß
Elektrolurch
Es gibt eine neue Version vom SIGNALduino per offiziellem Update (die Firmware läuft auf der FHEMduino Hardware), die kann SOMFY senden und empfangen. Auch diverse Temperatursensoren und IT-Protokolle werden bedient. Ich habe meinen nanoCUL und den FHEMduino durch den SD ersetzt, also nur umgeflasht und so einen USB-Steckplatz gewonnen.
Die durch das Somfy Modul angelegten Geräte können weiter genutzt werden, es muss nur das Attribut IODev auf den NAmen des SD gesetzt werden. Die Handsendergeräte werden wie gehabt angelegt.
Damit besteht allerdings das Problem weiterhin, dass das SOMFY-Modul die rawDevice-Funktionalität nicht besitzt. Hier ist dann weiterhin eine Lösung mit per notify und setreading <gerätename> state <parsestate vom zugehörigen Handsender> notwendig.
Hier mal das Gerüst des notify, das ich benutze:
SOMFY_(1B123|2C62D|3ABC3|54321).:parsestate:.(on|off|stop) {
# <Handsendergerätename> => <FHEM-Gerätename>
my %ger1 = (
"SOMFY_1B1230" => "WZ__Fenster",
"SOMFY_1B1231" => "WZ__Terasse",
"SOMFY_1B1232" => "WZ__Erker_L",
"SOMFY_1B1233" => "WZ__Erker_M",
"SOMFY_1B1234" => "WZ__Erker_R",
"SOMFY_2C62D1" => "OG__Schlafzimmer",
"SOMFY_2C62D2" => "OG__Bad",
"SOMFY_2C62D3" => "0",
"SOMFY_2C62D4" => "WZ__Fenster,WZ__Terasse,WZ__Erker_L,WZ__Erker_M,WZ__Erker_R",
"SOMFY_2C62D5" => "OG__Schlafzimmer,OG__Bad",
"SOMFY_3ABC33" => "WZ__Aussen",
"SOMFY_3ABC34" => "0",
"SOMFY_3ABC35" => "WZ__Terasse",
"SOMFY_3ABC36" => "OG__Schlafzimmer,OG__Bad",
"SOMFY_3ABC37" => "0",
"SOMFY_54321D" => "WZ__Fenster,WZ__Terasse,WZ__Erker_L,WZ__Erker_M,WZ__Erker_R"
);
my %cmd1 = (
"off" => "open",
"on" => "closed",
"stop" => "go-my"
# "prog" => "prog"
);
return undef unless ($ger1{$NAME} and $cmd1{$EVTPART1});
fhem "setreading $ger1{$NAME} state $cmd1{$EVTPART1}";
#Log 1, "setreading $ger1{$NAME} state $cmd1{$EVTPART1}";
}
@viegener:
Wäre es möglich, das für den SD angepasste SOMFY-Modul offiziell per Update bereitzustellen?
@Elektrolurch
Fertig bestellbar habe ich noch keine gesehen.
Mit den Antennen sind 8 Drähte an den Arduino nano zu löten
Hier die links zum WIKI-Eintrag
http://www.fhemwiki.de/wiki/SIGNALduino
http://www.fhemwiki.de/wiki/FHEMduino
Zitat von: Ellert am 04 Oktober 2016, 10:38:08
Damit besteht allerdings das Problem weiterhin, dass das SOMFY-Modul die rawDevice-Funktionalität nicht besitzt.
Hallo Ellert, das sollte mit der manuellen Anlage eines FHEMduino_SomfyR device unter Verwendung des Sendecodes des Somfy-Moduls aber auch möglich sein. Quasi ein Dummi, der zwischen den beiden Devices "vermittelt" (hat beim Gruppen-Somfy-Device auch auf Anhieb geklappt). Kann ich morgen Abend mal testen.
@ Elektrolurch:
was ein wenig tricky war beim Fhemduino, war das flashen, da man selber eine hex generieren muss, ansonsten habe ich es auch mit meinen zwei linken Händen hinbekommen. Zum Testen habe ich erstmal Jumperkabel (female/female) zum Verbinden Arduino, Empfänger und Sender verwendet. Werde es aber später löten, um es auch kompakter zu gestalten
Beim Signalduino ist im Modul die hex zum flashen enthalten und man kann ihn aus Fhem heraus direkt flashen.
Vorerst möchte ich mich bei den Entwicklern für dieses Modul herzlich bedanken. Ich verwende es für einen Zipscreen. Es funktioniert grundsätzlich gut, aber ein Problem ergibt sich dabei:
Da in der unteren Endposition ja keine Elemente zusammengeschoben werden, ist drive-down-time-to-100 gleich drive-down-time-to-close und drive-up-time-to-100 = 0, wenn ich die command-ref richtig verstanten habe. Wenn ich das so mache, werden aber die Zwischenschritte nicht richtig berechnet. Ich sehe nur "state" Werte von 100,90,0 oder 0,10,100 und nichts dazwischen. Wenn ich hingegen drive-down-time-to-close nur um 0.01 Sekunden größer mache, funktioniert die Anzeige wie erwartet.
Kein großese Problem, aber vielleicht könntet ihr euch das einmal ansehen. Nochmals vielen danke für die tolle Arbeit.
Zitat von: tremichl am 26 Oktober 2016, 16:11:16
Vorerst möchte ich mich bei den Entwicklern für dieses Modul herzlich bedanken. Ich verwende es für einen Zipscreen. Es funktioniert grundsätzlich gut, aber ein Problem ergibt sich dabei:
Da in der unteren Endposition ja keine Elemente zusammengeschoben werden, ist drive-down-time-to-100 gleich drive-down-time-to-close und drive-up-time-to-100 = 0, wenn ich die command-ref richtig verstanten habe. Wenn ich das so mache, werden aber die Zwischenschritte nicht richtig berechnet. Ich sehe nur "state" Werte von 100,90,0 oder 0,10,100 und nichts dazwischen. Wenn ich hingegen drive-down-time-to-close nur um 0.01 Sekunden größer mache, funktioniert die Anzeige wie erwartet.
Kein großese Problem, aber vielleicht könntet ihr euch das einmal ansehen. Nochmals vielen danke für die tolle Arbeit.
Ich habe das gerade mal bei mir nachgestellt, mit den folgenden Werten
drive-down-time-to-100 22
drive-down-time-to-close 22
drive-up-time-to-100 0
drive-up-time-to-open 26
Daber kann ich das Problem bei mir nicht nachstellen. Hast Du eine aktuelle Version und mit welchen Werten hast Du es probiert?
Hallo!
Hatte die Version von Mai 2016 in Verwendung. Nach update auf Version vom 26.10.2016 tritt der Effekt nicht mehr auf. :) Danke!!!
attr DG.Rollo drive-down-time-to-100 27.00
attr DG.Rollo drive-down-time-to-close 27.00
attr DG.Rollo drive-up-time-to-100 0
attr DG.Rollo drive-up-time-to-open 29.00
LG tremichl
Hallo, ich benötige einmal einen Rat bei der Ansteuerung mehrerer Somfy-RTS Rolläden mittels des "at" Befehls.
Ich steuere 3 RTS Rolläden mittels CUL v3 (433 Mhz) an, die Rolläden sollen morgens gleichzeitig hochfahren, abends zeitgleich herunter:
define RolladenSchliessen at *{sunset(0,"19:00","23:59")} set 100_Rolladen,101_Rolladen,102_Rolladen on
define RolladenOeffnen at *{sunrise(0,"04:00","07:00")} set 100_Rolladen,101_Rolladen,102_Rolladen off
Das funktioniert grundsätzlich gut, doch hin und wieder reagiert einer der 3 Rolläden ("101_Rolladen") nicht auf den Befehl.
Wenn das passiert, ist dieser Rolladen zudem auch nicht mehr über einen Handsender zu schließen / öffen.
Er scheint dann im Anlernmodus zu ein...
Fragen:
1. Was könnte die Ursache für das "Verschlucken" des Befehls sein?
2. Sollte ich die Rolläden besser einzeln schalten und für jeden einen eigenen "at"-Befehl definieren?
2. Gibt es andere, bessere Konstrukte, um 3 devices zeitgleich in FHEM zu schalten?
ich habe auch immer wieder Probleme bei befehlen, die an mehrere Somfy Rollladen gleichzeitig gehen. Seltsamerweise immer die gleichen Verdächtigen. Ich habe deswegen meine Befehle "gesplittet" dann läuft es. ich denke das die Somfy Empfänger bei zuviel Befehlen gleichzeitig manchmal Verständnisprobleme haben
Zitat von: defdanny am 02 November 2016, 21:25:33
Hallo, ich benötige einmal einen Rat bei der Ansteuerung mehrerer Somfy-RTS Rolläden mittels des "at" Befehls.
Ich steuere 3 RTS Rolläden mittels CUL v3 (433 Mhz) an, die Rolläden sollen morgens gleichzeitig hochfahren, abends zeitgleich herunter:
define RolladenSchliessen at *{sunset(0,"19:00","23:59")} set 100_Rolladen,101_Rolladen,102_Rolladen on
define RolladenOeffnen at *{sunrise(0,"04:00","07:00")} set 100_Rolladen,101_Rolladen,102_Rolladen off
Das funktioniert grundsätzlich gut, doch hin und wieder reagiert einer der 3 Rolläden ("101_Rolladen") nicht auf den Befehl.
Wenn das passiert, ist dieser Rolladen zudem auch nicht mehr über einen Handsender zu schließen / öffen.
Er scheint dann im Anlernmodus zu ein...
Fragen:
1. Was könnte die Ursache für das "Verschlucken" des Befehls sein?
2. Sollte ich die Rolläden besser einzeln schalten und für jeden einen eigenen "at"-Befehl definieren?
2. Gibt es andere, bessere Konstrukte, um 3 devices zeitgleich in FHEM zu schalten?
Du könntest 3 set-Befehle in einem at absetzen und FHEM sleep zwischen die Befehle setzen.
"structure" wäre auch eine Möglichkeit.
Zitat von: Garbsen am 02 November 2016, 22:28:37
ich habe auch immer wieder Probleme bei befehlen, die an mehrere Somfy Rollladen gleichzeitig gehen. Seltsamerweise immer die gleichen Verdächtigen. Ich habe deswegen meine Befehle "gesplittet" dann läuft es. ich denke das die Somfy Empfänger bei zuviel Befehlen gleichzeitig manchmal Verständnisprobleme haben
Leider gibt es dafür auch keine einfache Lösung, das Somfy-Protokoll ist da wohl etwas anfällig. Die Befehlesübertragung dauert relativ lange und erfordert auch relativ lange Pausen zwischen den Befehlen. Je nach Generation reagieren die Empfänger auch unterschiedlich. Das der Empfänger allerdings im Programmiermodus landet ist mir noch nicht passiert, dazu ist normalerweise ein spezieller Befehl mit relativ hoher Widerholrate erforderlich.
Ich weiss das hilft jetzt nicht weiter, aber der Hinweis mit Sleep zwischen den Befehlen ist bisher auch der beste Ansatz um das zu lösen.
Vielen Dank für alle helfenden Antworten! Gibt es hier im Thread schon ein Beispiel für die "sleep" Variante? Ansonsten werde ich morgen auf die Suche gehen.
Gesendet von meinem Tab2A7-10F mit Tapatalk
Mit DOIF (http://fhem.de/commandref_DE.html#DOIF) geht es so:
([{sunset(0,"19:00","23:59")}])
(set ...)
(set ...)
(set ...)
und die Atibute
wait 0,2,2
do always
HILFE !
ich habe gerade einen meiner Somfy Rolladen beibringen müssen das er alle seine Sender vergessen soll (max Anzahl erreicht, durch diverse neuanlern Orgien)
Nun mußte ich aus "Gründen" meine Hardware Sender aussen vor lassen und habe nun als winzigsten Sender Fhem anlernen müssen. Nun wollte ich die RTS Fernbedienung neu belegen und diesen Rolladen auch wieder auf die Fernbedienung legen. Nun habe ich festgestellt das der prog Befehl den Antrieb nicht in den Lernmodus versetzt, wie die Prog Tasten auf den Sendern das tun.
Frage also: Gibt es eine Möglichkeit den Antrieb per Fehm in den Prog Modus zu versetzten um zusätzliche Sender anzulernen ?
Ich hoffe ja....
Gruß Skusi
Zitat von: Skusi am 15 November 2016, 18:36:09
HILFE !
ich habe gerade einen meiner Somfy Rolladen beibringen müssen das er alle seine Sender vergessen soll (max Anzahl erreicht, durch diverse neuanlern Orgien)
Nun mußte ich aus "Gründen" meine Hardware Sender aussen vor lassen und habe nun als winzigsten Sender Fhem anlernen müssen. Nun wollte ich die RTS Fernbedienung neu belegen und diesen Rolladen auch wieder auf die Fernbedienung legen. Nun habe ich festgestellt das der prog Befehl den Antrieb nicht in den Lernmodus versetzt, wie die Prog Tasten auf den Sendern das tun.
Frage also: Gibt es eine Möglichkeit den Antrieb per Fehm in den Prog Modus zu versetzten um zusätzliche Sender anzulernen ?
Ich hoffe ja....
Gruß Skusi
Ich habe vor langer Zeit es mal geschafft das über das Attribut repetition zu erreichen. Dazu das Attribut repetition auf den Wert 15 setzen unnd den prog Befehl senden. Kann gerade nicht ausprobieren, ob das stabil funktioniert. Nicht vergessen das Attribut danach wieder zu löschen.
Hallo viegener
Zitat von: viegener am 15 November 2016, 22:00:15
Ich habe vor langer Zeit es mal geschafft das über das Attribut repetition zu erreichen. Dazu das Attribut repetition auf den Wert 15 setzen unnd den prog Befehl senden. Kann gerade nicht ausprobieren, ob das stabil funktioniert. Nicht vergessen das Attribut danach wieder zu löschen.
Danke für den Tipp. So hat es dann auch geklappt. Ich musste zwar meinen Original Busware CUL wieder rauskramen, da der Clone wie ja bekannt mit der Menge der Daten sich aufhängt. Aber der CUL hat es beim ersten Versuch geschluckt.
Nun ist alles wieder im Lot.
Danke und Gruß...
Skusi
Hallo zusammen,
ich hatte mal meinen SOMFY/SIMU Rolladen angelernt und eingerichtet. Es hatte soweit alles funktioniert. Dann ist mein nanoCUL@433 (Selbstbau) jedoch kaputt gegangen. Nachdem ich mir einen neuen gebaut habe, wird der Rolladen nicht mehr gesteuert. Also hab ich das Device gelöscht und unter einer anderen Adresse wieder neu angelegt. Mit dem Wandtaster schicke ich den Rollagen in den Anlernmodus. Ein "Prog" über FHEM wird aber wohl ignoriert.
Wie kann ich rausfinden, ob das eine Software Sache oder ein Hardware-Fehler (z.B. falsche Frequenz des Funkmoduls) ist?
Der Eventmonitor zeigt beim Anlernversuch
2016-12-30 20:14:33 CUL nanoCUL UNKNOWNCODE ? (YsA2800012000004 is unknown) Use one of A B C e F f G i K L l M N R T t U V W X x
define wz_Rolladen SOMFY 000004
attr wz_Rolladen IODev nanoCUL
attr wz_Rolladen devStateIcon open:fts_window_2w@black 10:fts_shutter_10 20:fts_shutter_20 30:fts_shutter_30 40:fts_shutter_40 50:fts_shutter_50 60:fts_shutter_60 70:fts_shutter_70 80:fts_shutter_80 90:fts_shutter_90 100:fts_shutter_100 close:fts_shutter_100@black
attr wz_Rolladen drive-down-time-to-100 24
attr wz_Rolladen drive-down-time-to-close 28
attr wz_Rolladen drive-up-time-to-100 4
attr wz_Rolladen drive-up-time-to-open 30
attr wz_Rolladen eventMap on:down off:up
attr wz_Rolladen group Rolladenstatus
attr wz_Rolladen room Wohnzimmer
attr wz_Rolladen webCmd stop:down:10:20:30:40:50:60:70:80:90:100:up
Update:
Jetzt hab ich das Device noch mal gelöscht und unter der "ganz" ursprünglichen Adresse 000001 neu angelegt. Dann habe ich den "rolling_code" bis "0BDD" durchlaufen lassen. Keine Reaktion :( Kann ich irgendwie erkennen, ob der Rolladen von fhem erkannt wurde? Oder könnte das ein "Reichweitenproblem" sein? Allerdings hatte das ja mit dem alten CUL geklappt.
@timtom: Die Meldung heisst für mich, dass Du in Deiner nanocul-Firmware das Somfy-Protokoll nicht aktiviert hast. Also erstmal ein Softwareproblem
Zitat von: viegener am 31 Dezember 2016, 00:11:13
@timtom: Die Meldung heisst für mich, dass Du in Deiner nanocul-Firmware das Somfy-Protokoll nicht aktiviert hast. Also erstmal ein Softwareproblem
Hey, danke für's Feedback. Das hat sich wohl mit meinem UPDATE (s.o.) überschnitten.
Firmware nutze ich vorkompilierte folgende:
V 1.23.04 a-culfw Build: 127 (2016-12-16_23-39-31) nanoCUL433 (F-Band: 433MHz)Laut Change-Log müsste Somfy doch bereits implementiert sein. Ich meine auch, dass auf dem "alten" CUL die a-culfw 1.21 oder so drauf hatte.
Moin,
In der neuen 1.23.xx ist Somfy und Hörmann meine ich im Standard auskommentiert. Die FW kann inzwischen soviel, dass der Platz nicht mehr reicht.
Siehe https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/nanoCUL/board.h und Zeile mit define HAS_SOMFY_RTS
Gibt es eigentlich eine Möglichkeit das dem CUL in FHEM zu entlocken? Ist z.b. get Commands spezifisch wenn Somfy oder Hörmann eingebaut ist?
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Zitat von: RaspiLED am 31 Dezember 2016, 03:24:53
Moin,
In der neuen 1.23.xx ist Somfy und Hörmann meine ich im Standard auskommentiert. Die FW kann inzwischen soviel, dass der Platz nicht mehr reicht.
Siehe https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/nanoCUL/board.h und Zeile mit define HAS_SOMFY_RTS
Gibt es eigentlich eine Möglichkeit das dem CUL in FHEM zu entlocken? Ist z.b. get Commands spezifisch wenn Somfy oder Hörmann eingebaut ist?
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Somfy lässt sich feststellen, wenn in den Kommandos des CUL das "Y" nicht gelistet ist. DIe Somfy-Commands sind alle Y....
Zitat von: RaspiLED am 31 Dezember 2016, 03:24:53
Moin,
In der neuen 1.23.xx ist Somfy und Hörmann meine ich im Standard auskommentiert. Die FW kann inzwischen soviel, dass der Platz nicht mehr reicht.
Siehe https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/nanoCUL/board.h und Zeile mit define HAS_SOMFY_RTS
Gibt es eigentlich eine Möglichkeit das dem CUL in FHEM zu entlocken? Ist z.b. get Commands spezifisch wenn Somfy oder Hörmann eingebaut ist?
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Zitat von: viegener am 31 Dezember 2016, 10:32:53
Somfy lässt sich feststellen, wenn in den Kommandos des CUL das "Y" nicht gelistet ist. DIe Somfy-Commands sind alle Y....
Danke zusammen. Das war's. In den vorkompilierten neuen a-culfw sind die Somfy (Y cmds) nicht mehr enhalten. Das hatte ich so im Changelog nicht gelesen. Mit 1.21 und bisschen rolling_code suchen geht es jetzt wieder.
D.h. wenn ich die neuste FW nutzen möchte, muss ich dieses selber kompilieren? :( Dann muss ich mal nach einem Tutorial für Dummys suchen. Danke auf jeden Fall noch einmal. Da wäre ich im Leben nicht drauf gekommen.
Hi,
ich habe die bitte sie Somfy Handsender für Garage/Licht einzubinden.
Alle Infos sind hier gesammelt:
https://forum.fhem.de/index.php/topic,24158.msg556123.html#msg556123
Es funktioniert jetzt schon aber nur durch zurücksetzen des Encryption Keys nach jedem Schaltvorgang.
Encryption Key bleibt bei diesen Sendern immer gleich.
Sollten weitere Infos nötig sein Bitte bei mir melden.
Gruß und Danke,
Stefan
Zitat von: stefanru am 08 Januar 2017, 13:25:33
Hi,
ich habe die bitte sie Somfy Handsender für Garage/Licht einzubinden.
Alle Infos sind hier gesammelt:
https://forum.fhem.de/index.php/topic,24158.msg556123.html#msg556123
Es funktioniert jetzt schon aber nur durch zurücksetzen des Encryption Keys nach jedem Schaltvorgang.
Encryption Key bleibt bei diesen Sendern immer gleich.
Sollten weitere Infos nötig sein Bitte bei mir melden.
Gruß und Danke,
Stefan
Ich habe mal eine Version in github bereitgestellt, die ein neues Attribut
fixed_enckey enthält, mit dem Wert 1 wird der enc key nicht mehr verändert.
Hi Viegener,
vielen Dank!
Werde es heute Abend testen.
Habe noch eine Frage:
Wäre es möglich bei den Devices andere Stati anzuzeigen?
Also für 2 Kanal ist taste 1 off:20 und teste2 stop:11
4 Kanal checke ich heute Abend noch.
Stati wär schön ch1 on/aus, ch2 an/aus, ch3 an/aus, ch4 an/aus. bzw auf/zu.
Es ist für jeden Kanal ein toggle Schalter.
Und mir ist noch eine besonderheit aufgefallen für die ich noch keine Erkläreung habe.
CH1 ist bei mir ein Funkschalter für Licht von Somfy und auf CH2 ein Garagentor.
CH1 lässt sich nicht per nanaoCUL schalten, setze IODEV auf den sduino geht es einwandfrei.
CH2 lässt sich nur per nanaoCUL schalten, setze ich IODEV auf den sduino geht nichts.
Wo ist denn da der Unterschied?
Das sollte doch jeweils mit beidem gehen.
Ich habe das device einfach kopiert und benutze nun für Garage den nanoCUL und fürs Licht den sduino als iodev. Das geht natürlich, ist aber sicher nicht so gedacht.
Testen kann ich gerne alles mögliche wenn du ideen hast.
Gruß,
Stefan
Zitat von: stefanru am 09 Januar 2017, 13:10:16
Hi Viegener,
vielen Dank!
Werde es heute Abend testen.
Habe noch eine Frage:
Wäre es möglich bei den Devices andere Stati anzuzeigen?
Also für 2 Kanal ist taste 1 off:20 und teste2 stop:11
4 Kanal checke ich heute Abend noch.
Stati wär schön ch1 on/aus, ch2 an/aus, ch3 an/aus, ch4 an/aus. bzw auf/zu.
Es ist für jeden Kanal ein toggle Schalter.
Und mir ist noch eine besonderheit aufgefallen für die ich noch keine Erkläreung habe.
CH1 ist bei mir ein Funkschalter für Licht von Somfy und auf CH2 ein Garagentor.
CH1 lässt sich nicht per nanaoCUL schalten, setze IODEV auf den sduino geht es einwandfrei.
CH2 lässt sich nur per nanaoCUL schalten, setze ich IODEV auf den sduino geht nichts.
Wo ist denn da der Unterschied?
Das sollte doch jeweils mit beidem gehen.
Ich habe das device einfach kopiert und benutze nun für Garage den nanoCUL und fürs Licht den sduino als iodev. Das geht natürlich, ist aber sicher nicht so gedacht.
Testen kann ich gerne alles mögliche wenn du ideen hast.
Gruß,
Stefan
Die Stati zu veränden wird nicht so einfach, denn das ganze Modul ist um das konzept eines Roilladen herumgebaut. Geschätzt 90% des Codes befasst sich mit Statusupdates für Rolläden. Hier wäre es vermutlich einfacher ein Modul zu bauen (z.B. aus dem intertechno oder FS20-Modul) und die Sende/Parsefunktionen auszutauschen.
Ich würde das auch machen, habe aber keine Devices bei mir, so dass das völlige Blindentwicklung wäre
Das mit dem unterschiedlichen Verhalten zwischen Signalduino und CUL ist mir ein Rätsel. Es gibt zwei mögliche Ansätze zur Erklärung:
- Kann es an Reichweiten liegen? Garagentor klingt weiter weg vielleicht kommt der Signalduino nicht so weit?
- SOMFY reagiert sensitiv auf bestimmte timings, leider ist aber das Protokoll nirgendwo dokumentiert, sondern es gibt ein paar Leute, die da eine tolle Arbeit gemacht haben und per testen das entschlüsselt haben (ich war da nicht beteiligt)
Leider kann ich auch da nicht wirklich helfen, denn ich kann das Verhalten nicht bei mir nachstellen
Hi viegener,
vielen herzlichen Dank.
Das mit den Stati hatte ich schon befürchtet.
Ich denke ich werde mich mal dran machen und das ganze in einem neuen pm das ich vom IT abkupfere einbauen.
Ich muss mal schauen wann ich Zeit dazu finde. Bei fragen würde ich mich dann gern nochmal bei dir melden.
Deine implementierung tut ja auch erstmal und ich gebe dir heute Abend bescheid ob es funktioniert, aber ich gehe davon aus.
Beim Garagentor könnte es tatsächlich die Reichweite sein, aber das Lichtrelais habe ich direkt an den Sendern liegen und es reagiert nur auf sduino und nich auf nanoCUL.
Auch habe ich bei den Rolläden bessere Erfahrungen mit dem nanaoCUL. Der sduino scheint sich da ab und zu zu verschlucken oder der Rolladen erkennt das Signal nciht immer.
Aber das Gute is es tut! Ich hab beide Sender. Ist halt nur ein komisches Verhalten.
Wenn ich mal ganz viel Zeit hab kann ich da auch mal etwas reinschauen und rumspielen.
Natürlich ist das Somfy Modul tolle Arbeit und ich habe wirklich höchsten Repekt für die ganze Arbeit des reverse engeniering des Funkprotokols.
Es ist wirklich klasse dass ich damit alles Steuern kann.
Danke und viele Grüße,
Stefan
Zitat von: stefanru am 09 Januar 2017, 16:35:56
Hi viegener,
vielen herzlichen Dank.
Das mit den Stati hatte ich schon befürchtet.
Ich denke ich werde mich mal dran machen und das ganze in einem neuen pm das ich vom IT abkupfere einbauen.
Ich muss mal schauen wann ich Zeit dazu finde. Bei fragen würde ich mich dann gern nochmal bei dir melden.
Deine implementierung tut ja auch erstmal und ich gebe dir heute Abend bescheid ob es funktioniert, aber ich gehe davon aus.
Beim Garagentor könnte es tatsächlich die Reichweite sein, aber das Lichtrelais habe ich direkt an den Sendern liegen und es reagiert nur auf sduino und nich auf nanoCUL.
Auch habe ich bei den Rolläden bessere Erfahrungen mit dem nanaoCUL. Der sduino scheint sich da ab und zu zu verschlucken oder der Rolladen erkennt das Signal nciht immer.
Aber das Gute is es tut! Ich hab beide Sender. Ist halt nur ein komisches Verhalten.
Wenn ich mal ganz viel Zeit hab kann ich da auch mal etwas reinschauen und rumspielen.
Natürlich ist das Somfy Modul tolle Arbeit und ich habe wirklich höchsten Repekt für die ganze Arbeit des reverse engeniering des Funkprotokols.
Es ist wirklich klasse dass ich damit alles Steuern kann.
Danke und viele Grüße,
Stefan
Ich habe nochmal überlegt, so einfach wird es möglicherweise doch nicht werden, ein separates Modul zu machen, das hängt mit der Struktur von FHEM zusammen (Senden sollte kein Problem sein, aber Empfangen , möglicherweise muss ich das dochmal im SOMFY-Modul etwas einbauen.
Gibt es andere Interessenten?
Kann mir jemand die Zuordnung für 4-Kanal geben?
Ok, danke.
4 Kanäle schicke ich dir heute Abend.
Gruß,
Stefan
Also die Kanäle sind:
oben links: CH1 = 20 => up
oben rechts: CH2 = 11 => stop
unten links: CH3 = 40 => down
unten rechts: CH4 = 30 => ??? keine Ahnung
Ein Bild im Anhang.
Gruß und danke,
Stefan
Zitat von: stefanru am 09 Januar 2017, 19:47:49
Also die Kanäle sind:
oben links: CH1 = 20 => up
oben rechts: CH2 = 11 => stop
unten links: CH3 = 40 => down
unten rechts: CH4 = 30 => ??? keine Ahnung
Ein Bild im Anhang.
Gruß und danke,
Stefan
Ich muss nochmal nachfragen, denn das was Du da beschreibst ist ja eigentlich der Sender (sprich Sensor) und nicht der Aktor. Der Somfy-Device repräsentiert ja eigentlich den Status des Aktors (also den Steckdosenschalter). Die Frage ist also welche Aktoren sind es und welche Stati haben diese?
Hi,
ja völlig richtig.
Der Sender ist ja schon abgebildet.
Die Aktoren sind Relais für 220V. Damit kann man z.B. Außenlischt schalten oder jeglichen 220V Verbraucher.
Oder es ist ein Garagentor öffner Somfy KaesyL.
Es gibt noch weitere Aktoren. Alle zum an/aus schalten.
Die Stati sind immer an und aus.
Wobei dies aber durch drücken eines Kanals getan wird. Sowohl beim Garagentor auf/zu bzw. beim licht an/aus.
Als Beispiel habe ich auf CH1 das Licht und auf CH2 das Garagentor. CH 3 und CH 4 sind noch nicht belegt.
Drücke ich also CH1 geht das Garagentor auf. Ein weiteres drücken lässt es zu fahren.
Drücke ich CH1 während der Fahrt des Tors bleibt es stehen. Alles nur mit CH1.
Beim Licht: Drücke ich CH2 geht es an. Drücke ich CH2 erneut geht es aus.
Hier die Aktoren.
http://i.ebayimg.com/images/g/zswAAOSwnHZYWta0/s-l1600.jpg <= Garage
https://www.amazon.de/Somfy-Funklichtschalter-1841008/dp/B000T7MXNQ <= Licht
Es gibt noch mehr Geräte die an/aus Funktion ermöglichen. Von Relais aller Arten, Garagentor Treiber bis hin zur Funksteckdose für 34€. :-) Verückt was die verlangen...
Viele Grüße,
Stefan
Zitat von: stefanru am 10 Januar 2017, 23:50:24
Hi,
ja völlig richtig.
Der Sender ist ja schon abgebildet.
Die Aktoren sind Relais für 220V. Damit kann man z.B. Außenlischt schalten oder jeglichen 220V Verbraucher.
Oder es ist ein Garagentor öffner Somfy KaesyL.
Es gibt noch weitere Aktoren. Alle zum an/aus schalten.
Die Stati sind immer an und aus.
Wobei dies aber durch drücken eines Kanals getan wird. Sowohl beim Garagentor auf/zu bzw. beim licht an/aus.
Als Beispiel habe ich auf CH1 das Licht und auf CH2 das Garagentor. CH 3 und CH 4 sind noch nicht belegt.
Drücke ich also CH1 geht das Garagentor auf. Ein weiteres drücken lässt es zu fahren.
Drücke ich CH1 während der Fahrt des Tors bleibt es stehen. Alles nur mit CH1.
Beim Licht: Drücke ich CH2 geht es an. Drücke ich CH2 erneut geht es aus.
Hier die Aktoren.
http://i.ebayimg.com/images/g/zswAAOSwnHZYWta0/s-l1600.jpg <= Garage
https://www.amazon.de/Somfy-Funklichtschalter-1841008/dp/B000T7MXNQ <= Licht
Es gibt noch mehr Geräte die an/aus Funktion ermöglichen. Von Relais aller Arten, Garagentor Treiber bis hin zur Funksteckdose für 34€. :-) Verückt was die verlangen...
Viele Grüße,
Stefan
Heisst das, das wirklich jeder Kanal eigenständig ist und einen Aktor umschaltet (toggelt) oder kann man es auch so konfigurieren, dass 1 Kanal fest EINschaltet und der andere AUS. Also ein zweimaliges Drücken des EINschaltknopfes schaltet nicht wieder aus?
Hintergrund - im ersten Fall müsste jeder Kanal ein separater Device sein und der STatus wäre unzuverlässig, da man ja u.U einen FUnkbefehl nicht mitbekommt
im zweiten Fall müsste man zusätzlich noch einen Device mit An/Aus status realisieren.
Hi,
Also diese Aktoren benutzen leider nur ein Kanal.
Man kann in den Garagentormotor mehrere Fernbedienungen anlernen, aber es bleibt immer eine ein Knopf Bedienung mit all den Nachteilen die du aufzählst.
Die Funkverbindung sollte schon stabil funktionieren um einen Status abgezogen zu lassen. Leider ist es nicht möglich eine 2 Knopf Bedienung für auf und zu, bzw an und aus einzustellen.
Viele Grüße,
Stefan
Zitat von: stefanru am 11 Januar 2017, 09:58:25
Hi,
Also diese Aktoren benutzen leider nur ein Kanal.
Man kann in den Garagentormotor mehrere Fernbedienungen anlernen, aber es bleibt immer eine ein Knopf Bedienung mit all den Nachteilen die du aufzählst.
Die Funkverbindung sollte schon stabil funktionieren um einen Status abgezogen zu lassen. Leider ist es nicht möglich eine 2 Knopf Bedienung für auf und zu, bzw an und aus einzustellen.
Viele Grüße,
Stefan
Für mich klingt das so, als ob Du mit einem Dummy und einem notify schneller zum Ziel kommst, denn in SOMFY würde ich es auch so realisieren, dass es pro Kanal dann einen Device gäbe und das Problem mit der Statusanzeige würde ich in Somfy auch ungerne realisieren, denn das wäre nicht wirklich gut für instabile Empfangslagen
Hi viegener,
das ist für mich auch ok.
Hatte ich auch schon mit rumgespielt.
Mir ist aber nicht ganz klar wie ich z.B. ein Dummy mit an und aus, mit einem notify auf an und aus schalten kann, wenn der trigger im notify z.B. immer off ist?
Wie bekomme ich den Toggel hin?
Brauch ich dann im Notify ein if auf den Dummy status?
Danke und viele Grüße,
Stefan
Zitat von: stefanru am 12 Januar 2017, 21:03:32
Hi viegener,
das ist für mich auch ok.
Hatte ich auch schon mit rumgespielt.
Mir ist aber nicht ganz klar wie ich z.B. ein Dummy mit an und aus, mit einem notify auf an und aus schalten kann, wenn der trigger im notify z.B. immer off ist?
Wie bekomme ich den Toggel hin?
Brauch ich dann im Notify ein if auf den Dummy status?
Danke und viele Grüße,
Stefan
Konzept im Telegrammstil
- Ein Dummy <schalter>, der den Schalter repräsentiert (on / off)
- Ein Notify bei Änderung des States von <schalter>, der den entsprechenden raw Befehl in Somfy absetzt
- Ein Notify, der bei Empfang eines Befehls durch FHEMDuino oder Signalduino - den Status des <schalters> umsetzt
(also on --> off / off --> on)
Hmmm,
leider geht es so nicht:
(also on --> off / off --> on)
Der Schlatvorgang ist ja somfy off --> dummy on und als nächste somfy off -> dummy off.
Der Trigger ist immer die selbe Aktion.
Denke es geht leider nur in etwa so (etwas umständlich und wohl nicht mit notify sondern mit doif):
somfy off -> if dummy on then dummy off elsif dummy on
Oder kennst du etwas besseres?
P.S.: wollte gerade dein GIT change ausprobieren, aber in dem GIT das hier am Anfang beschrieben ist finde ich nix.
https://github.com/thdankert/somfy-rts-fhem
Habs gefunden:
https://github.com/viegener/Telegram-fhem
Warum heißt das Telegram?
fixed enc_key tut perfekt! Vielen Dank!
Danke und Gruß,
Stefan
Moin,
sobald ich ein Befehl über ein Somfy-Device absetze erscheint keine Meldung als Event.
Ist das so gewollt? Dadurch funktioniert nämlich logischerweise auch kein longpoll.
Gruß
Hmmm,
ich habe somfy auch im Tablet UI und der longpoll tut.
Kannst du mir etwas genauer erklären was du meinst?
Gruß,
Stefan
Zitat von: stefanru am 12 Januar 2017, 21:34:27
Hmmm,
leider geht es so nicht:
(also on --> off / off --> on)
Der Schlatvorgang ist ja somfy off --> dummy on und als nächste somfy off -> dummy off.
Der Trigger ist immer die selbe Aktion.
Denke es geht leider nur in etwa so (etwas umständlich und wohl nicht mit notify sondern mit doif):
somfy off -> if dummy on then dummy off elsif dummy on
Oder kennst du etwas besseres?
P.S.: wollte gerade dein GIT change ausprobieren, aber in dem GIT das hier am Anfang beschrieben ist finde ich nix.
https://github.com/thdankert/somfy-rts-fhem
Habs gefunden:
https://github.com/viegener/Telegram-fhem
Warum heißt das Telegram?
fixed enc_key tut perfekt! Vielen Dank!
Danke und Gruß,
Stefan
Schön dass es geht!
Eigentlich ist dies hier nicht der richtige Thread, als ich das Modul übernommen habe habe ich einen neuen Thread erstellt.
Telegram heisst es, weil das mein Sammelrepository für alle meine FHEM-Module ist (und telegram das erste war)
Zitat von: stefanru am 20 Januar 2017, 21:24:49
ich habe somfy auch im Tablet UI und der longpoll tut.
Kannst du mir etwas genauer erklären was du meinst?
Habe jetzt zum testen ein frischen FHEM aufgesetzt. Ein Somfy Device und ein Dummy angelegt:
define dummy1 dummy
attr dummy1 webCmd wert1:wert2:wert3
define rollo_test SOMFY 000001Im Event monitor werden allerdings nur die Events vom Dummy angezeigt:
2017-01-20 23:43:58 dummy dummy1 wert1
2017-01-20 23:43:59 dummy dummy1 wert2
2017-01-20 23:43:59 dummy dummy1 wert3Ein "set rollo_test on|off|stop" gibt keine Ausgabe im Monitor (auf dem Produktivsystem reagieren die angelernten Rollläden natürlich).
Dadurch das keine Events entstehen kann longpoll natürlich auch in FTUI nicht funktionieren. Das Widget holt sich erst mit Aktualisierung der Seite den aktuellen state.
Also bei meinem Somfy device gibt es state und postition.
Außerdem benutze ich kein dummy im Tablet UI.
So diehts im Tablet UI für den Status aus. Direkt am Somfy device.
<div data-type="symbol"
data-device="EG.RolloBuero"
data-icons='["oa-fts_window_2w","oa-fts_shutter_100","oa-fts_window_2w","oa-fts_shutter_100","oa-fts_shutter","oa-fts_shutter_10","oa-fts_shutter_20","oa-fts_shutter_30","oa-fts_shutter_40","oa-fts_shutter_50","oa-fts_shutter_60","oa-fts_shutter_70","oa-fts_shutter_80","oa-fts_shutter_90","oa-fts_shutter_100"]'
data-states='["open","closed","[0-9]","1[0-9]","2[0-9]","3[0-9]","4[0-9]","5[0-9]","6[0-9]","7[0-9]","8[0-9]","9[0-9]","100"]'
data-colors='["green","red","white","white","white","white","white","white","white","white","white","white","white"]'
data-background-icon=" "></div>
Das device im FHEM:
defmod EG.RolloBuero SOMFY 000001
attr EG.RolloBuero userattr SOMFY SOMFY_map structexclude
attr EG.RolloBuero IODev mapleCUL433
attr EG.RolloBuero SOMFY EG.AlleRollos
attr EG.RolloBuero alias Rollo Büro
attr EG.RolloBuero cmdIcon offen:fts_shutter_up geschlossen:fts_shutter_down stop:rc_STOP go-my:fts_shutter_manual lüftung:vent_ventilation_level_manual_m pos:fts_shutterupdown
attr EG.RolloBuero devStateIcon 100:fts_shutter_100 up:fts_window_2w@green open:fts_window_2w@green down:fts_shutter_100@black closed:fts_shutter_100@black 1\d.*:fts_shutter_10 2\d.*:fts_shutter_20 3\d.*:fts_shutter_30 4\d.*:fts_shutter_40 5\d.*:fts_shutter_50 6\d.*:fts_shutter_60 7\d.*:fts_shutter_70 8\d.*:fts_shutter_80 9\d.*:fts_shutter_90
attr EG.RolloBuero drive-down-time-to-100 13.00
attr EG.RolloBuero drive-down-time-to-close 16.80
attr EG.RolloBuero drive-up-time-to-100 3.60
attr EG.RolloBuero drive-up-time-to-open 18.00
attr EG.RolloBuero eventMap /off:offen/on:geschlossen/pos 100:lüftung/pos 90:Dämmerung/pos 80:Sonnenschutz/go-my:go-my/
attr EG.RolloBuero group EG.Rollos
attr EG.RolloBuero room SOMFY
attr EG.RolloBuero webCmd offen:stop:geschlossen:go-my:lüftung:pos
setstate EG.RolloBuero open
setstate EG.RolloBuero 2017-01-21 12:06:06 enc_key AF
setstate EG.RolloBuero 2017-01-21 12:06:24 exact 0
setstate EG.RolloBuero 2017-01-21 12:06:07 parsestate off
setstate EG.RolloBuero 2017-01-21 12:06:24 position 0
setstate EG.RolloBuero 2017-01-21 12:06:06 rolling_code 016F
setstate EG.RolloBuero 2017-01-21 12:06:24 state open
Das funktioniert bei mir einwandfrei mit SOMFY.
Gruß,
Stefan
Danke für die Antwort.
Den Dummy habe ich nur zum testen von longpoll verwendet.
Habe Dein Device mal übertragen und damit klappt es. Danach noch etwas rumprobiert und rausgefunden, dass die Attribute:
attr rollo_test drive-down-time-to-100 5.00
attr rollo_test drive-down-time-to-close 6.00
attr rollo_test drive-up-time-to-100 5.00
attr rollo_test drive-up-time-to-open 6.00
gesetzt sein müssen. Sonst gibt es kein Event vom Somfy-Device. Ist das so gewollt?
Ich wollte mich eh mal an die Laufzeiten setzen und eintragen, aber aktuell wurde das eben noch nicht realisiert.
Hi pataya,
ob das so gewollt ist kann ich nicht sagen,
Aber ohne eine Zeit kann er natürlich auch nicht sagen wo der Rollo ist da die Komunikation ja nur unidoirektional ist.
Der Rolladen meldet ja nicht wo er ist.
Gruß,
Stefan
Hi viegener,
könntest du irgendwann den fixed_enckey ins repository einchecken?
Nervt immer nach jedem Update wieder die Somfy.pm auszutauschen.
Es funktioniert super damit und nochmals vielen Dank!
Apropos wo finde ich den Telegram Thread?
Gruß,
Stefan
Zitat von: stefanru
Der Rolladen meldet ja nicht wo er ist.
Schon richtig, allerdings sollte ein auf/zu genügen. Der Befehl wird ja schließlich ausgeführt und auch der state wird aktualisiert. Nur wird dafür eben kein Event erzeugt.
Sei es drum, werde die Zeiten ja eh bald eintragen 8)
Zitat von: stefanruNervt immer nach jedem Update wieder die Somfy.pm auszutauschen.
Solang deine Änderung noch nicht eingecheckt ist, kannst du das Modul vom Update ausschließen:
attr global exclude_from_update 10_SOMFY.pm
Guten Tag, kompletter Neuling hier. Ich versuche gerade, meine Somfy Rolladen anzulernen (ich habe einen Telis 1 RTS Handsender und einen Rolladenmotor Oximo RTS 20/17). Ich habe den Handsender in Programmiermodus gebracht und dann
Internals
ADDRESS 000001
CFGFN CUL_MSGCNT 4
CUL_RAWMSG YsA34F0003010000
CUL_TIME 2017-01-24 13:40:07
DEF 000001
IODev CUL
LASTInputDev CUL
MSGCNT 4
NAME RolladenTerasse
NR 53
STATE open
TYPE SOMFY move off
Readings
enc_key A5
2017-01-24 13:40:52 exact 0
2017-01-24 13:40:52 parsestate off
2017-01-24 13:40:53 position 0
2017-01-24 13:40:52 rolling_code 0005
2017-01-24 13:40:52 state open
2017-01-24 13:40:52 attr RolladenTerasse
Attributes
IODev CUL
verbose 0
dies hier umgesetzt. Ich finde weder einen Eintrag im Logfile noch bewegt sich der Rolladen. Leider steht im Wiki nicht mehr, als ich bisher umsetzen konnte. Kann mir jemand freundlicherweise weiterhelfen? Ich will doch nur die Rolladen via FHEM ansteuern...
Hi andies,
kurzfassung.
Du musst zuerst das Device wie du es auch schreibst anlegen.
Dann musst du per handsender deinen Rollo in den Prog modus bringen (Prog taste am Handsender drücken bis der Rollo mit kurzer auf/ab bewegung bestätigt).
Der Rollo ist nun lernwillig.
Nun musst du im FHEM an deinem device per set den prog Befehl senden. Damit deine "virtuelle"/"neue" Fernbdienung vom FHEM auch eingelernt wird.
Der Rolladen sollte wieder mit auf/ab Bewegung bestätigen.
Das ist dass Zeichen dass er nun auch deine FHEM Fernbedienung akzeptiert. Er kennt dann also 2 Stück.
Gruß,
Stefan
Vielen Dank, hat geklappt.
@viegener: Weiterentwicklung SOMFY
aktuell wird pro Fernbedienung ein SOMFY-Device angelegt. Diese entspricht nicht dem Status eines Rollladens, der durch mehrere Fernbedienungen verändert werden kann.
Auch Gruppen (mehrere Blind reagieren auf eine ID) sind denkbar.
Hältst du eine entsprechende Erweiterung für machbar (mehrere IDs nebst Enc-Key und Rolling-Code an einem Device verwalten; entsprechende Management-Funktion zum zusammen führen; etc.)?
@habeIchVergessen: Ja ein solcher Umbau ist denkbar. Da sich im Somfy-Modul inzwischen sehr viel historischer Code angesammelt hat, würde ich dazu das Modul wohl in grossen Teilen neu schreiben.
Das Konzept Der multiplen Adressen müsste aber noch überlegt werden, ob wirklich die verschiedenen Adressen in einem Device sein sollten oder ob man auf eine Kopplung zwischen verschiedenen Devices setzt.
Dabei würden sich auch ein paar andere Dinge umsetzen lassen, die schon länger angedacht waren.
Zitat von: viegener am 01 Februar 2017, 00:41:39
@habeIchVergessen: Ja ein solcher Umbau ist denkbar. Da sich im Somfy-Modul inzwischen sehr viel historischer Code angesammelt hat, würde ich dazu das Modul wohl in grossen Teilen neu schreiben.
Das Konzept Der multiplen Adressen müsste aber noch überlegt werden, ob wirklich die verschiedenen Adressen in einem Device sein sollten oder ob man auf eine Kopplung zwischen verschiedenen Devices setzt.
Dabei würden sich auch ein paar andere Dinge umsetzen lassen, die schon länger angedacht waren.
Das Bessere ist zwar immer der Feind des Guten, aber umfangreiche Änderungen an Modulen bergen natürlich auch immer die Gefahr von neuen Fehlern, nicht vorhergesehenen Änderungen im Verhalten bei komplexen Einrichtungen etc.
Wunsch/Vorschlag:
Kannst Du beim Neuschreiben die alte und die neue Version parallel laufen lassen? D.h. Quasi ein Somfy_Neu Modul?
Dann könnten wir dummen Anwender die Neuerungen schrittweise ausprobieren, ohne Gefahr zu laufen, dass die bestehende Rolladensteuerung zu spinnen an fängt. Ist ja ein durchaus kritischer Teil der Haussteuerung, der bei Fehlfunktionen den Ärger der gesamten Familie auf sich zieht und bei dem Fehlverhalten immer möglichst schnell abgestelltwerden sollte.
dann schlage folgende Arbeitshypothese bzgl. der Rollos (R1 - R4) und Fernbedienungen (FB physikalisch; FE logische in FHEM) vor.
Pro Rollo können max. 12 FBs angelernt werden.
| ID | Beschreibung | R1 | R2 | R3 | R4 |
| 000FB0 | phys. FB Kanal 1 | x | | | |
| 000FB1 | phys. FB Kanal 2 | | x | | |
| 000FB2 | phys. FB Kanal 3 | x | x | | |
| 000FB3 | phys. FB Kanal 4 | | x | x | x |
| 111FE0 | log. FB fhem | x | | | |
| 111FE1 | log. FB fhem | | x | | |
| 111FE2 | log. FB fhem | | | x | |
| 111FE3 | log. FB fhem | | | | x |
| 222FE0 | Gruppe Wohnzimmer | x | x | | |
| 222FE1 | Gruppe Küche | | | x | x |
| 222FE2 | Gruppe Südseite | x | | x | |
| 222FE3 | Gruppe Sichtschutz | x | x | | |
| 222FE4 | Gruppe Alle | x | x | x | x |
Zitat von: habeIchVergessen am 01 Februar 2017, 15:44:11
dann schlage folgende Arbeitshypothese bzgl. der Rollos (R1 - R4) und Fernbedienungen (FB physikalisch; FE logische in FHEM) vor.
Pro Rollo können max. 12 FBs angelernt werden.
| ID | Beschreibung | R1 | R2 | R3 | R4 |
| 000FB0 | phys. FB Kanal 1 | x | | | |
| 000FB1 | phys. FB Kanal 2 | | x | | |
| 000FB2 | phys. FB Kanal 3 | x | x | | |
| 000FB3 | phys. FB Kanal 4 | | x | x | x |
| 111FE0 | log. FB fhem | x | | | |
| 111FE1 | log. FB fhem | | x | | |
| 111FE2 | log. FB fhem | | | x | |
| 111FE3 | log. FB fhem | | | | x |
| 222FE0 | Gruppe Wohnzimmer | x | x | | |
| 222FE1 | Gruppe Küche | | | x | x |
| 222FE2 | Gruppe Südseite | x | | x | |
| 222FE3 | Gruppe Sichtschutz | x | x | | |
| 222FE4 | Gruppe Alle | x | x | x | x |
ich muss zu geben ich verstehe das oben nicht, speziell was die Frage angeht, ob die Fernbedienungen eigene Geräte sein sollten.
Nach dem HM-Konzept wären ein Motor/Aktor und eine FB - 2 Devices zwischen denen ein Peering existiert und zusätzlich gäbe es eine virtuelle FB, die in FHEM zum Steuern verwendet werden kann...
Wenn man das auflöst und der Motor repräsentiert einen Device mit allen FB, dann hat das andere Vorteile (# devices / einfachererer Umbau / ...)
ich hatte versucht darzustellen, welches Rollo von welcher Fernbedienung gesteuert wird.
Nur eine fiktives Anwendungsszenario, dass die Ausgangssituation und zu betrachtende Kombinatorik darstellt.
OK, verstanden.
Mein Ansatz wäre, dass es zwei Arten von Somfy-Devices gibt
a) Aktoren - diese haben einen Status, der die Position des Rollos, Markis, Rolladen angibt - Jeder Aktor hat auch eine Adresse, die von FHEM benutzt wird um den Aktor zu steuern
b) Reine Fernbedienungen- diese haben die Adresse aus der FB und können mit einem oder mehreren Aktoren gepeered sein - Liste von Aktor-Adressen
Pro Adresse nur ein Device - Identifikation des devices über die Adresse (nicht über Namen)
Beide Devicetypen haben dieselbe rolling-code/etc - Logik / Autocreate wäre möglich
Einziges Szenario, dass ich bisher sehe, dass nicht abgebildet werden kann sind mehrere Aktoren, die man anfangs als Einheit anlegt (Typ a - ein Device) und später trennen möchte
Offene Punkte
- Ein oder 2 Module -> Vermutlich würde es bei einem Modul bleiben
- Status-Info für reine Fernbedienungen
- Wie kann man möglich viel Code weiterverwenden
- Besserer Status für Aktoren (on/off)
- Wie kann man ein paar Altlasten aufräumen - Position 200-0 und invers - Rollingcode handling passt nicht für Signalduino - ...
- Wunschliste - Peers sollten als Namen angezeigt werden aber als Adresse (zwecks Eindeutigkeit) verwaltet werden
Gerade der Punkt mit den Altlasten würde inkompatible Änderungen erfordern, wäre aber schön, denn momentan bekommt man einen Knoten ins Gehirn, wenn man versucht den Code zur Positionsberechnung zu verstehen
Zu dem oben aufgebrachten Punkt: Nein ich würde wohl kein Somfy_Neu danebenstellen, sondern einen ausgiebigen Betatest veranstalten. Dann kann es eine automatische Migration geben, die Zuordnung für Parse würde funktionieren. Trotzdem wären Nacharbeiten erforderlich, da es doch einige Änderungen geben würde (siehe offene Punkte)
Das mal so als ad hoc design ;)
Zitat von: viegener am 02 Februar 2017, 11:47:34
OK, verstanden.
Mein Ansatz wäre, dass es zwei Arten von Somfy-Devices gibt
a) Aktoren - diese haben einen Status, der die Position des Rollos, Markis, Rolladen angibt - Jeder Aktor hat auch eine Adresse, die von FHEM benutzt wird um den Aktor zu steuern
b) Reine Fernbedienungen- diese haben die Adresse aus der FB und können mit einem oder mehreren Aktoren gepeered sein - Liste von Aktor-Adressen
Pro Adresse nur ein Device - Identifikation des devices über die Adresse (nicht über Namen)
Beide Devicetypen haben dieselbe rolling-code/etc - Logik / Autocreate wäre möglich
Einziges Szenario, dass ich bisher sehe, dass nicht abgebildet werden kann sind mehrere Aktoren, die man anfangs als Einheit anlegt (Typ a - ein Device) und später trennen möchte
Offene Punkte
- Ein oder 2 Module -> Vermutlich würde es bei einem Modul bleiben
- Status-Info für reine Fernbedienungen
- Wie kann man möglich viel Code weiterverwenden
- Besserer Status für Aktoren (on/off)
- Wie kann man ein paar Altlasten aufräumen - Position 200-0 und invers - Rollingcode handling passt nicht für Signalduino - ...
- Wunschliste - Peers sollten als Namen angezeigt werden aber als Adresse (zwecks Eindeutigkeit) verwaltet werden
Gerade der Punkt mit den Altlasten würde inkompatible Änderungen erfordern, wäre aber schön, denn momentan bekommt man einen Knoten ins Gehirn, wenn man versucht den Code zur Positionsberechnung zu verstehen
Zu dem oben aufgebrachten Punkt: Nein ich würde wohl kein Somfy_Neu danebenstellen, sondern einen ausgiebigen Betatest veranstalten. Dann kann es eine automatische Migration geben, die Zuordnung für Parse würde funktionieren. Trotzdem wären Nacharbeiten erforderlich, da es doch einige Änderungen geben würde (siehe offene Punkte)
Das mal so als ad hoc design ;)
@viegener
Tatsächlich verhält es sich etwas anders.
1. Es gibt Fernbedienungen und Aktoren.
1.1 Hardware-Fernbedienungen (Schaltuhren, Handsender, Windwächter, Sonnenwächter, usw.) besitzen Adressen. Jede Adresse verhält sich wie eine Fernbedienung und kann Up, Down, Stop, Programm senden.
1.2 Es gibt virtuelle Fernbedienungen, die FHEM-Somfy-Geräte, denen der Benutzer eine beliebige Adresse zuweist. Beliebig insofern als es eine gültige Somfy-Adresse sein muss und keine der Hardware-Fernbedienungen diese Adresse besitzt.
2 Aktoren habe keine Adresse, sie müssen die Adressen der Fernbedienungen lernen (von Hardware und FHEM-Somfy-Geräten), von denen Sie gesteuert werden sollen (maximal 25 Adressen kann ein Aktor lernen).
Ein aktuelles FHEM-Gerät des Somfy-Moduls bildet eine Fernbedienung nach (Senden von Up, Down, Stop, Programm) und bildet einen Aktor nach (Richtungs- und Positionsangaben). Es sind aber nur die Fernbedinungs-Komponente des Gerätes mit der Aktorkomponente des gleichen Gerätes verknüpft.
Die Aktor-Komponente müsste so erweitert werden, dass sie die Adressen von anderen Fernbedienungen lernen kann (durch manuellen Eintrag), damit die Aktor-Komponente des Gerätes reagieren kann. (Für den FHEMduino ist das ja ansatzweise schon realisiert.)
Zitat von: Ellert am 02 Februar 2017, 13:45:33
@viegener
Tatsächlich verhält es sich etwas anders.
1. Es gibt Fernbedienungen und Aktoren.
1.1 Hardware-Fernbedienungen (Schaltuhren, Handsender, Windwächter, Sonnenwächter, usw.) besitzen Adressen. Jede Adresse verhält sich wie eine Fernbedienung und kann Up, Down, Stop, Programm senden.
1.2 Es gibt virtuelle Fernbedienungen, die FHEM-Somfy-Geräte, denen der Benutzer eine beliebige Adresse zuweist. Beliebig insofern als es eine gültige Somfy-Adresse sein muss und keine der Hardware-Fernbedienungen diese Adresse besitzt.
2 Aktoren habe keine Adresse, sie müssen die Adressen der Fernbedienungen lernen (von Hardware und FHEM-Somfy-Geräten), von denen Sie gesteuert werden sollen (maximal 25 Adressen kann ein Aktor lernen).
Ein aktuelles FHEM-Gerät des Somfy-Moduls bildet eine Fernbedienung nach (Senden von Up, Down, Stop, Programm) und bildet einen Aktor nach (Richtungs- und Positionsangaben). Es sind aber nur die Fernbedinungs-Komponente des Gerätes mit der Aktorkomponente des gleichen Gerätes verknüpft.
Die Aktor-Komponente müsste so erweitert werden, dass sie die Adressen von anderen Fernbedienungen lernen kann (durch manuellen Eintrag), damit die Aktor-Komponente des Gerätes reagieren kann. (Für den FHEMduino ist das ja ansatzweise schon realisiert.)
Deshalb habe ich geschrieben das wäre MEIN Ansatz, denn natürlich ist mir klar, dass Aktoren keine Adresse haben ;)
IM Somfy-Modul ist es heute so konzipiert, dass sie virtuelle FB und Aktor in einem Device repräsentieren (implizit gepeered innerhalb des moduls) - das sollte man auch nicht trennen, denn dann wäre Status des Aktors und deren Bedienung nicht mehr im selben Device - das wäre nicht sinnvoll.
Heir ist SOmfy halt anders als HM und andere, da keine Aktor-ID/Adresse existiert.
Ich glaube aber Du meinst vermutlich dasselbe wie ich - Nur schlage ich vor weitere Fernbedienungen (oder in meiner Beschreibung REINE Fernbedienungen) auch als separate Devices anzulegen und nur einmal RollingCode per Device zu haben und die Verbindung zwischen Reiner FB (Typ b) und Aktor+FB (Typ a) als "Peering" zu gestalten
Ja, jetzt sehe ich auch, dass wir beide das Gleiche meinen.
Aktor a) ist der virtuelle Aktor des FHEM-Gerätes, das auch die FHEM Fernbedienung (mit selbst festgelegter Adresse) darstellt.
Fernbedienung b) ist das per autocreate angelegte Gerät der Hardware Fernbedienung.
Fernbedienung b) (und ggf. weitere reine FB) müsste mit dem Aktor a) gepeert werden.
Damit ist die Übereinstimmung hergestellt.
Zitat von: Ellert am 02 Februar 2017, 15:48:10
Ja, jetzt sehe ich auch, dass wir beide das Gleiche meinen.
Aktor a) ist der virtuelle Aktor des FHEM-Gerätes, das auch die FHEM Fernbedienung (mit selbst festgelegter Adresse) darstellt.
Fernbedienung b) ist das per autocreate angelegte Gerät der Hardware Fernbedienung.
Fernbedienung b) (und ggf. weitere reine FB) müsste mit dem Aktor a) gepeert werden.
Damit ist die Übereinstimmung hergestellt.
Das klingt gut!
Dann nochmal die offenen Punkte für die weitere Diskussion:
Offene Punkte
- Ein oder 2 Module -> Vermutlich würde es bei einem Modul bleiben
- Status-Info für reine Fernbedienungen
- Wie kann man möglich viel Code weiterverwenden
- Besserer Status für Aktoren (on/off)
- Wie kann man ein paar Altlasten aufräumen - Position 200-0 und invers - Rollingcode handling passt nicht für Signalduino - ...
- Wunschliste - Peers sollten als Namen angezeigt werden aber als Adresse (zwecks Eindeutigkeit) verwaltet werden
Gerade der Punkt mit den Altlasten würde inkompatible Änderungen erfordern, wäre aber schön, denn momentan bekommt man einen Knoten ins Gehirn, wenn man versucht den Code zur Positionsberechnung zu verstehen
Meinungen und Vorschläge sind willkommen !
(Und ich habe noch keine Ahnung wann ich die Zeit für den Umbau hätte, beim Blick in den Code kann ich sagen, dass der Aufwand auch stark von den Altlasten / Migrationsaufwänden ab)
LaCross verwaltet intern (glaube DevPtr) eine zentrale Liste aller bekannten IDs. Wären für Somfy dann die FBs, die weiterhin einmalig EncKey und RollingCode verwalten.
Die eigentlichen Devices wären dann die nur noch die Rollos mit einer Liste der assoziierten FBs.
Interessant wird es, wenn mehrere Rollos einer FB zugeordnet sind (Gruppe).
Ist das ein eigenständiges Device?
Mit Statusanzeige?
Was zeigt diese an, wenn erst die Gruppe geschlossen und anschließend ein einzelnes Rolle wieder geöffnet wird?
Zitat von: viegener am 02 Februar 2017, 16:29:09
Das klingt gut!
Dann nochmal die offenen Punkte für die weitere Diskussion:
Offene Punkte
- Ein oder 2 Module -> Vermutlich würde es bei einem Modul bleiben
- Status-Info für reine Fernbedienungen
- Wie kann man möglich viel Code weiterverwenden
- Besserer Status für Aktoren (on/off)
- Wie kann man ein paar Altlasten aufräumen - Position 200-0 und invers - Rollingcode handling passt nicht für Signalduino - ...
- Wunschliste - Peers sollten als Namen angezeigt werden aber als Adresse (zwecks Eindeutigkeit) verwaltet werden
Gerade der Punkt mit den Altlasten würde inkompatible Änderungen erfordern, wäre aber schön, denn momentan bekommt man einen Knoten ins Gehirn, wenn man versucht den Code zur Positionsberechnung zu verstehen
Meinungen und Vorschläge sind willkommen !
(Und ich habe noch keine Ahnung wann ich die Zeit für den Umbau hätte, beim Blick in den Code kann ich sagen, dass der Aufwand auch stark von den Altlasten / Migrationsaufwänden ab)
Lt. Statistik gibt es 173 Installationen, die das Somfy-Modul nutzen und kaum Probleme aufzeigen, daher würde ich am Modul nur kleine Änderungen vornehmen und ein neues Modul verwerfen.
Zunächst vielleicht erstmal die per autocreate angelegten Hardware-Fernbedienungen auf die Aktorenkomponente der reinen FB mappen.
Also
HWFB:parsestate => reineFB:state
"off" => "open",
"on" => "closed",
"stop" => "go-my"
"prog" => "prog"
damit wäre eine Grundlegende Verknüpfung erreicht.
Zitat von: habeIchVergessen am 02 Februar 2017, 22:27:14
LaCross verwaltet intern (glaube DevPtr) eine zentrale Liste aller bekannten IDs. Wären für Somfy dann die FBs, die weiterhin einmalig EncKey und RollingCode verwalten.
Die eigentlichen Devices wären dann die nur noch die Rollos mit einer Liste der assoziierten FBs.
Interessant wird es, wenn mehrere Rollos einer FB zugeordnet sind (Gruppe).
Ist das ein eigenständiges Device?
Mit Statusanzeige?
Was zeigt diese an, wenn erst die Gruppe geschlossen und anschließend ein einzelnes Rolle wieder geöffnet wird?
Nein, die Fernbedienungen sollten schon getrennte Devices sein, das wäre sonst für mich irgendwie nicht gut vereinbar mit dem Konzept von Devices-Aktoren-Sensoren. Die Adressen muss man trotzdem im Modulhash verwalten.
Ein Rollo/Rolläden sollte einen eigenen Status haben - wenn eine Fernbedienung mehreren Rolläden zugeordnet ist dann hat trotzdem jeder Rolladen einen eigenen Status. Ein Gruppenstatus macht eigentlich keinen Sinn für mich
Zitat von: Ellert am 02 Februar 2017, 23:45:04
Lt. Statistik gibt es 173 Installationen, die das Somfy-Modul nutzen und kaum Probleme aufzeigen, daher würde ich am Modul nur kleine Änderungen vornehmen und ein neues Modul verwerfen.
Den Satz verstehe ich nicht?
Die Menge der Nutzer ist überschaubar und ich gehe davon aus, wenn keine Probleme bestehen, dass niemand seine Definitionen ändert, um ein Somfy2-Modul zu verwenden. Ein geringer Bestand, bei seit langem vorhandener Technik, lässt nicht erwarten, dass er sich stark vergrößert. Von daher würde ich auch nicht viele neue Nutzer eines neuen Moduls erwarten.
Und ich denke überschaubare Änderungen senken die Wahrscheinlichkeit, dass bestehende Definitionen gestört werden.
Es gibt 13 Set-Befehle, wenn die z.B. geändert werden, würde ich viele Probleme erwarten.
Denke auch, dass die Somfy RTS Steuerungen eher eine aussterbende Spezies sind. Wobei sie laufen stabil und für jeden, der die (seit langem) im Einsatz hat, ist FHEM eine der wenigen (wenn nicht einzige) Lösung diese alten Teile in eine moderne Haussteuerung einzubauen.
Sprich: potentiell gibt es viele Leute, die die Teile eingebaut haben und potentiell sind das alles "Kunden" für FHEM.
Meine Bitte wäre wirklich, mit Änderungen sehr vorsichtig zu sein. Am liebsten würde ich immer noch ein neues Modul sehen, dass es ermöglicht, das bestehende Modul und die funktionierende Steuerung beizubehalten.
also wir haben neu gebaut, und es sind somfy rts verbaut bei uns. also ist es immer noch nicht so veraltet das es keine neuen mehr gibt, die es nutzen.
ich habe z.b. jetzt mit etwas maja grauen haren die shutter nun am laufen.
nur hats mir den rollcode verhagelt als ich alle (10 stück ) per notify runterfahren lassen wollte, immer mit fhem{xxxx;;sleep 10;;xxxx} usw
erst hat es geklapt, dann auf einmal hatte eine nicht mehr reagiert, kurze zeit später auf einmal keine mehr.
hatte dann doppelte sendeversuche gemacht, also roll1;;sleep 2;;roll1 usw. ging auch ned.
naja hab es dann wieder rausgeworfen, und habe rumgesucht und nach einerweile lief eine bei mir wieder, und hab dann festgestellt das der rollcode sich bei allen verschoben hatte.
dennoch funktioniert es, soweit.
Zitat von: Garbsen am 03 Februar 2017, 16:39:39
Denke auch, dass die Somfy RTS Steuerungen eher eine aussterbende Spezies sind. Wobei sie laufen stabil und für jeden, der die (seit langem) im Einsatz hat, ist FHEM eine der wenigen (wenn nicht einzige) Lösung diese alten Teile in eine moderne Haussteuerung einzubauen.
Sprich: potentiell gibt es viele Leute, die die Teile eingebaut haben und potentiell sind das alles "Kunden" für FHEM.
Meine Bitte wäre wirklich, mit Änderungen sehr vorsichtig zu sein. Am liebsten würde ich immer noch ein neues Modul sehen, dass es ermöglicht, das bestehende Modul und die funktionierende Steuerung beizubehalten.
Ich habe bisher nicht unbedingt den Eindruck, dass SOMFY-RTS schon am Aussterben ist, es werden nachwievor neue Geräte produziert und auch verkauft. Deshalb ist der Ausdruck "alte Teile" vielleicht etwas übertrieben.
Ein neues Modul ist wie schon geschrieben keine Alternative, denn dann muss wirklich jeder manuelle tätig werden und auf absehbare Zeit müssten zwei Versionen gepflegt werden.
Die eigentlich Frage ist für mich:
Die heutige Positionswerte von 0-200 passt eigentlich nicht in FHEM (und auch nicht in homebridge etc) - eine Position von 100-0 wäre viel besser.
Hm das mit den Positionen ist mir noch ein Rätsel. Denn egal ob ich 50 oder 10 die fährt immer ganz auf oder zu.
Wobei man dabei sagen muss der Panzer ist recht flink. Brauch grade mal 13 Sekunden vom luftschlitz bis ganz auf.
Gesendet von meinem E6853 mit Tapatalk
@BlackStone: Wie sind denn die attribute zur laufzeit gesetzt im device?
Zitat von: viegener am 05 Februar 2017, 21:30:28
Ich habe bisher nicht unbedingt den Eindruck, dass SOMFY-RTS schon am Aussterben ist, es werden nachwievor neue Geräte produziert und auch verkauft. Deshalb ist der Ausdruck "alte Teile" vielleicht etwas übertrieben.
Ein neues Modul ist wie schon geschrieben keine Alternative, denn dann muss wirklich jeder manuelle tätig werden und auf absehbare Zeit müssten zwei Versionen gepflegt werden.
Die eigentlich Frage ist für mich:
Die heutige Positionswerte von 0-200 passt eigentlich nicht in FHEM (und auch nicht in homebridge etc) - eine Position von 100-0 wäre viel besser.
Ich plädiere trotzdem für 2 Module, das alte könnte dann ja nach 1 Jahr oder so obsolet gemacht werden. Dann hätte aber jeder Zeit seine Devices stückweise umzustellen. Ich sehe nicht, dass es ohne manuelle Anpassungen funktionieren wird (lasse mich gern eines besseren belehren)
Bei 20 Rolläden ist das schon ein gewisser Zeitaufwand, der bei einem Modul dann an einem Tag notwendig ist und die Gefahr von Fehlern bei der Umstellung besteht auch noch. Ich komme z.B. oft nur am WE und da auch nur eingeschränkt zu solchen Umstellarbeiten. Wenn das dann nicht klappt, fahren evtl. Einzelne Rollos für eine ganze Woche nicht. Wäre unschön, zumal ich die Rolläden auch nicht (und nur umständlich) manuell fahren kann
Zitat von: Garbsen am 06 Februar 2017, 09:09:38
Ich plädiere trotzdem für 2 Module, das alte könnte dann ja nach 1 Jahr oder so obsolet gemacht werden. Dann hätte aber jeder Zeit seine Devices stückweise umzustellen. Ich sehe nicht, dass es ohne manuelle Anpassungen funktionieren wird (lasse mich gern eines besseren belehren)
Bei 20 Rolläden ist das schon ein gewisser Zeitaufwand, der bei einem Modul dann an einem Tag notwendig ist und die Gefahr von Fehlern bei der Umstellung besteht auch noch. Ich komme z.B. oft nur am WE und da auch nur eingeschränkt zu solchen Umstellarbeiten. Wenn das dann nicht klappt, fahren evtl. Einzelne Rollos für eine ganze Woche nicht. Wäre unschön, zumal ich die Rolläden auch nicht (und nur umständlich) manuell fahren kann
Das Problem lässt sich relativ leicht lösen in dem Du entweder Somfy für einige Zeit vom Update ausnimmst oder das Update dann machst, wenn Du testen kannst oder das alte Modul sogar zurückspielst wenn es Probleme gibt.
Mit ist auch nicht klar, welche grosse Anzahl / Aufwände bei den Umstellarbeiten Du erwartest?
Das einzige was bisher geplant wäre ist die Positionswerte 0-200 auf 100-0 umzubauen - das betrifft nur exakte Positionierungen und auch da würde ich wohl versuchen einen Kompatibilitätsmodus zu schaffen.
Interessant wäre zu wissen, welche Aufgaben automatisiert sind (also welche Befehle du da ausführst), dann kann man das auch im vorhinein testen - Auch eine Vorabinstallation einer Entwicklungsversion wäre möglich.
Also es gibt dafür Lösungen
Zitat von: Garbsen am 03 Februar 2017, 16:39:39
Denke auch, dass die Somfy RTS Steuerungen eher eine aussterbende Spezies sind. Wobei sie laufen stabil und für jeden, der die (seit langem) im Einsatz hat, ist FHEM eine der wenigen (wenn nicht einzige) Lösung diese alten Teile in eine moderne Haussteuerung einzubauen.
Sprich: potentiell gibt es viele Leute, die die Teile eingebaut haben und potentiell sind das alles "Kunden" für FHEM.
Ich habe gerade zwei Somfy-Steuerungen gekauft und der Hauptgrund, zu FHEM zu wechseln, war genau Somfy. Pilight beispielsweise schafft das wegen der "falschen" Frequenz nicht. Ich würde mich freuen, wenn Ihr dranbleibt (ich kann leider nicht so gut programmieren und steige schon bei der Analyse des Sendeprotokolls aus).
@viegener:
Ich denke ob Kompabilität problemlos machbar ist, kannst du besser beurteilen. Ich bin nur skeptischer Anwender, der schon die Frage wie man ein Modul vom Update ausschließt erstmal rausfinden muss.
Nutzen tue ich das Modul für die üblichen Befehel (Auf, Ab, Stop) sowie das Anfahren definierter Positionen (Sonnenschutz)
Da ich die Rolläden auch in Homebridge eingebunden habe nutze ich das PositionInverse Attribut.
Die Befehle sende ich per doif und auch mittels einer Fernbedienung (auch über doif ).
K-H
@garbsen: Ausschliessen vom update ist über das global attribute exclude_from_update möglich
Wenn Du positionInverse nutzt sollte es ja sogar genau in Deinem Sinne sein, denn das wäre genau die zentrale Änderung.
On/off/stop sollte unverändert gehen das wäre schön so sehe ich das auch ;)
Aber jetzt höre ich erstmal auf zu diskutieren und versuche mal mehr Zeit zu finden die Umbauten zu machen.
Zitat von: viegener am 06 Februar 2017, 08:43:04
@BlackStone: Wie sind denn die attribute zur laufzeit gesetzt im device?
mit stoppuhr gemessen.
drive down to 100 / complett offen bis runter das nur noch die lüftungsschlite offen sind.
bis close ist so knapp dran das es nur noch im komma bereich liegt statt 13, 56 ihrgenwas um , 96
up to 100 von komplett dicht bis lüftungsschlitz
up to open komplett geschlossen bis komplett auf.
Internals:
.eventMapCmd Auf:noArg Zu:noArg Stop:noArg Sonne:noArg
ADDRESS 000059
DEF 000059
IODev CUL_0
NAME rollBuero
NR 50
STATE down
TYPE SOMFY
move stop
Code:
1 000059
Readings:
2017-02-06 16:54:55 enc_key A9
2017-02-06 18:06:15 exact 10
2017-01-03 17:13:51 parsestate on
2017-02-06 18:06:15 position 10
2017-02-06 16:54:55 rolling_code 00E9
2017-02-06 18:06:15 state down
Attributes:
IODev CUL_0
drive-down-time-to-100 13
drive-down-time-to-close 13
drive-up-time-to-100 3
drive-up-time-to-open 13
eventMap off:Auf on:Zu stop:Stop go-my:Sonne
model somfyshutter
positionInverse 1
room Rolladen
webCmd Auf: Stop: Zu:Sonnekeine ahnung warum, die geht wirklich hoch wie runter gleich.
edit:/ hab mir den spass gemacht, mit einer anderen stoppuhr noch mal zu messen.
evtl. ist die andere ja ned ganz in ordnung, naja nach einem alter von ca. 30 jahrn^^.
Internals:
.eventMapCmd Auf:noArg Zu:noArg Stop:noArg Sonne:noArg
ADDRESS 000059
DEF 000059
IODev CUL_0
NAME rollBuero
NR 50
STATE closed
TYPE SOMFY
move stop
Code:
1 000059
Readings:
2017-02-06 18:55:30 enc_key AA
2017-02-06 18:55:45 exact 0
2017-01-03 17:13:51 parsestate on
2017-02-06 18:55:45 position 0
2017-02-06 18:55:30 rolling_code 00EA
2017-02-06 18:55:45 state closed
Attributes:
IODev CUL_0
drive-down-time-to-100 13
drive-down-time-to-close 15
drive-up-time-to-100 3
drive-up-time-to-open 17
eventMap off:Auf on:Zu stop:Stop go-my:Sonne
model somfyshutter
positionInverse 1
room Rolladen
webCmd Auf: Stop: Zu:Sonne# $Id: 10_SOMFY.pm 12918 2016-12-31 10:10:47Z viegener $ein z.b.
set rollBuero pos 50 sollte doch den shutter auf hälfte fahren ?
wirkt leider wie jeder andere pos nur wie ein toogle, unabhängig von positionInverse.
@BlackStone: kannst Du mal folgendes ausprobieren? Rolladen ganz öffnen und schauen, dass das auch so im Device wiedergespiegelt ist.
Attribut verbose auf 5 setzen und dann mal set ... pos 50 ausführen.
Vielleicht kannst Du den Log ausschnitt dann mal posten - vielleicht gibt es ja einen Fehler. Am besten mit den zweiten Timingwerten, wo ..-close ...-100 sich unterscheiden.
@Blackstone:
Ich meine mich dunkel erinnern zu können, dass ich das Problem beim Einrichten auch einmal hatte. Die Lösung ergab sich m.E. nachdem ich die Zeit für to 100 und to close um 1 sek unterschiedlich gesetzt hatte.
Vielleicht kannst du das ja mal ausprobieren.
Sodale einmal die logauszüge..
erst runtergefahren und dann mit verbose 5
hoch gefahren, dann pos 50 und nach stillstand nochmals pos 50
2017.02.07 17:46:57 4: SOMFY_set: rollBuero Inverse before cmd:off: arg1:: pos:0:
2017.02.07 17:46:57 4: SOMFY_set: rollBuero Inverse after cmd:off: arg1:: pos:200:
2017.02.07 17:46:57 4: SOMFY_set: rollBuero -> entering with mode :send: cmd :off: arg1 :: pos :200:
2017.02.07 17:46:57 4: SOMFY_set: handled command off --> move :off: newState :200:
2017.02.07 17:46:57 5: SOMFY_set: handled for drive/udpate: updateState :0: drivet :0: updatet :17:
2017.02.07 17:46:57 4: SOMFY_UpdateState: rollBuero enter with newState:200: updatestate:0: move:off:
2017.02.07 17:46:57 4: SOMFY_UpdateState: rollBuero after conversions newState:0: rounded:0: stateTrans:closed:
2017.02.07 17:46:57 4: SOMFY_sendCommand: rollBuero -> cmd :off:
2017.02.07 17:46:57 5: SOMFY_sendCommand: rollBuero -> message :sAA2000FA000059:
2017.02.07 17:46:57 4: SOMFY_set: rollBuero -> update state in 17 sec
2017.02.07 17:46:57 4: SOMFY_set: rollBuero Inverse before cmd:off: arg1:: pos:0:
2017.02.07 17:46:57 4: SOMFY_set: rollBuero Inverse after cmd:off: arg1:: pos:200:
2017.02.07 17:46:57 4: SOMFY_set: rollBuero -> entering with mode :virtual: cmd :off: arg1 :: pos :200:
2017.02.07 17:46:57 4: SOMFY_set: handled command off --> move :off: newState :194:
2017.02.07 17:46:57 5: SOMFY_set: handled for drive/udpate: updateState :0: drivet :0: updatet :16.79:
2017.02.07 17:46:57 4: SOMFY_UpdateState: rollBuero enter with newState:194: updatestate:0: move:off:
2017.02.07 17:46:57 4: SOMFY_UpdateState: rollBuero after conversions newState:0.6: rounded:0: stateTrans:closed:
2017.02.07 17:46:57 4: SOMFY_set: rollBuero -> update state in 16.79 sec
2017.02.07 17:46:58 1: usb create starting
2017.02.07 17:46:58 3: Probing CUL device /dev/ttyAMA0
2017.02.07 17:46:59 3: Probing TCM_ESP3 device /dev/ttyAMA0
2017.02.07 17:46:59 3: Probing FRM device /dev/ttyAMA0
2017.02.07 17:47:04 1: usb create end
2017.02.07 17:47:04 3: CUL_0: Unknown code YsAA2B00FA590000, help me!
2017.02.07 17:47:04 4: SOMFY_TimedUpdate
2017.02.07 17:47:04 5: SOMFY_TimedUpdate : pos before convert so far : 0.6
2017.02.07 17:47:04 5: SOMFY_TimedUpdate : pos so far : 194
2017.02.07 17:47:04 5: SOMFY_TimedUpdate : delta time : 6.96 new rounde pos (rounded): 70.4285714285714
2017.02.07 17:47:04 4: SOMFY_UpdateState: rollBuero enter with newState:70.4285714285714: updatestate:0: move:off:
2017.02.07 17:47:04 4: SOMFY_UpdateState: rollBuero after conversions newState:36.6142857142857: rounded:40: stateTrans:40:
2017.02.07 17:47:04 4: SOMFY_TimedUpdate: rollBuero -> update state in 9.83 sec
2017.02.07 17:47:04 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486486027.53336
2017.02.07 17:47:04 5: SOMFY_TimedUpdate DONE
2017.02.07 17:47:07 4: SOMFY_TimedUpdate
2017.02.07 17:47:07 5: SOMFY_TimedUpdate : pos before convert so far : 36.6142857142857
2017.02.07 17:47:07 5: SOMFY_TimedUpdate : pos so far : 70.4285714285714
2017.02.07 17:47:07 5: SOMFY_TimedUpdate : delta time : 2.99 new rounde pos (rounded): 49.0714285714286
2017.02.07 17:47:07 4: SOMFY_UpdateState: rollBuero enter with newState:49.0714285714286: updatestate:0: move:off:
2017.02.07 17:47:07 4: SOMFY_UpdateState: rollBuero after conversions newState:55.8357142857143: rounded:60: stateTrans:60:
2017.02.07 17:47:07 4: SOMFY_TimedUpdate: rollBuero -> update state in 6.84 sec
2017.02.07 17:47:07 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486486030.5274
2017.02.07 17:47:07 5: SOMFY_TimedUpdate DONE
2017.02.07 17:47:10 4: SOMFY_TimedUpdate
2017.02.07 17:47:10 5: SOMFY_TimedUpdate : pos before convert so far : 55.8357142857143
2017.02.07 17:47:10 5: SOMFY_TimedUpdate : pos so far : 49.0714285714286
2017.02.07 17:47:10 5: SOMFY_TimedUpdate : delta time : 2.99 new rounde pos (rounded): 27.7142857142857
2017.02.07 17:47:10 4: SOMFY_UpdateState: rollBuero enter with newState:27.7142857142857: updatestate:0: move:off:
2017.02.07 17:47:10 4: SOMFY_UpdateState: rollBuero after conversions newState:75.0571428571429: rounded:80: stateTrans:80:
2017.02.07 17:47:10 4: SOMFY_TimedUpdate: rollBuero -> update state in 3.85 sec
2017.02.07 17:47:10 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486486033.52077
2017.02.07 17:47:10 5: SOMFY_TimedUpdate DONE
2017.02.07 17:47:13 4: SOMFY_TimedUpdate
2017.02.07 17:47:13 5: SOMFY_TimedUpdate : pos before convert so far : 75.0571428571429
2017.02.07 17:47:13 5: SOMFY_TimedUpdate : pos so far : 27.7142857142857
2017.02.07 17:47:13 5: SOMFY_TimedUpdate : delta time : 2.99 new rounde pos (rounded): 6.35714285714283
2017.02.07 17:47:13 4: SOMFY_UpdateState: rollBuero enter with newState:6.35714285714283: updatestate:0: move:off:
2017.02.07 17:47:13 4: SOMFY_UpdateState: rollBuero after conversions newState:94.2785714285715: rounded:90: stateTrans:90:
2017.02.07 17:47:13 4: SOMFY_TimedUpdate: rollBuero -> update state in 0.859999999999998 sec
2017.02.07 17:47:13 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486486034.3744
2017.02.07 17:47:13 5: SOMFY_TimedUpdate DONE
2017.02.07 17:47:14 4: SOMFY_TimedUpdate
2017.02.07 17:47:14 5: SOMFY_TimedUpdate : pos before convert so far : 94.2785714285715
2017.02.07 17:47:14 5: SOMFY_TimedUpdate : pos so far : 6.35714285714283
2017.02.07 17:47:14 5: SOMFY_TimedUpdate : delta time : 0.85 new rounde pos (rounded): 0.285714285714258
2017.02.07 17:47:14 4: SOMFY_UpdateState: rollBuero enter with newState:0: updatestate:<undef>: move:stop:
2017.02.07 17:47:14 4: SOMFY_UpdateState: rollBuero after conversions newState:100: rounded:100: stateTrans:open:
2017.02.07 17:47:14 5: SOMFY_TimedUpdate DONE
2017.02.07 17:51:05 4: SOMFY_set: rollBuero Inverse before cmd:pos: arg1:50: pos:100:
2017.02.07 17:51:05 4: SOMFY_set: rollBuero Inverse after cmd:pos: arg1:55.5555555555556: pos:0:
2017.02.07 17:51:05 4: SOMFY_set: rollBuero -> entering with mode :send: cmd :pos: arg1 :55.5555555555556: pos :0:
2017.02.07 17:51:05 4: SOMFY_set: handled command pos --> move :on: newState :0:
2017.02.07 17:51:05 5: SOMFY_set: handled for drive/udpate: updateState :55.5555555555556: drivet :7.22222222222222: updatet :0:
2017.02.07 17:51:05 4: SOMFY_UpdateState: rollBuero enter with newState:0: updatestate:55.5555555555556: move:on:
2017.02.07 17:51:05 4: SOMFY_UpdateState: rollBuero after conversions newState:100: rounded:100: stateTrans:open:
2017.02.07 17:51:05 4: SOMFY_sendCommand: rollBuero -> cmd :on:
2017.02.07 17:51:05 5: SOMFY_sendCommand: rollBuero -> message :sAB4000FB000059:
2017.02.07 17:51:05 4: SOMFY_set: rollBuero -> stopping in 7.22222222222222 sec
2017.02.07 17:51:06 4: SOMFY_set: rollBuero Inverse before cmd:on: arg1:: pos:100:
2017.02.07 17:51:06 4: SOMFY_set: rollBuero Inverse after cmd:on: arg1:: pos:0:
2017.02.07 17:51:06 4: SOMFY_set: rollBuero -> entering with mode :virtual: cmd :on: arg1 :: pos :0:
2017.02.07 17:51:06 4: SOMFY_set: handled command on --> move :on: newState :2:
2017.02.07 17:51:06 5: SOMFY_set: handled for drive/udpate: updateState :200: drivet :0: updatet :14.79:
2017.02.07 17:51:06 4: SOMFY_UpdateState: rollBuero enter with newState:2: updatestate:200: move:on:
2017.02.07 17:51:06 4: SOMFY_UpdateState: rollBuero after conversions newState:98.2: rounded:100: stateTrans:open:
2017.02.07 17:51:06 4: SOMFY_set: rollBuero -> update state in 14.79 sec
2017.02.07 17:51:06 1: usb create starting
2017.02.07 17:51:07 3: Probing CUL device /dev/ttyAMA0
2017.02.07 17:51:07 3: Probing TCM_ESP3 device /dev/ttyAMA0
2017.02.07 17:51:07 3: Probing FRM device /dev/ttyAMA0
2017.02.07 17:51:13 1: usb create end
2017.02.07 17:51:13 3: CUL_0: Unknown code YsAB4D00FB590000, help me!
2017.02.07 17:51:13 4: SOMFY_TimedUpdate
2017.02.07 17:51:13 5: SOMFY_TimedUpdate : pos before convert so far : 98.2
2017.02.07 17:51:13 5: SOMFY_TimedUpdate : pos so far : 2
2017.02.07 17:51:13 5: SOMFY_TimedUpdate : delta time : 6.97 new rounde pos (rounded): 55.6153846153846
2017.02.07 17:51:13 4: SOMFY_UpdateState: rollBuero enter with newState:55.6153846153846: updatestate:200: move:on:
2017.02.07 17:51:13 4: SOMFY_UpdateState: rollBuero after conversions newState:49.9461538461538: rounded:50: stateTrans:50:
2017.02.07 17:51:13 4: SOMFY_TimedUpdate: rollBuero -> update state in 7.82 sec
2017.02.07 17:51:13 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486486276.04429
2017.02.07 17:51:13 5: SOMFY_TimedUpdate DONE
2017.02.07 17:51:16 4: SOMFY_TimedUpdate
2017.02.07 17:51:16 5: SOMFY_TimedUpdate : pos before convert so far : 49.9461538461538
2017.02.07 17:51:16 5: SOMFY_TimedUpdate : pos so far : 55.6153846153846
2017.02.07 17:51:16 5: SOMFY_TimedUpdate : delta time : 2.99 new rounde pos (rounded): 78.6153846153846
2017.02.07 17:51:16 4: SOMFY_UpdateState: rollBuero enter with newState:78.6153846153846: updatestate:200: move:on:
2017.02.07 17:51:16 4: SOMFY_UpdateState: rollBuero after conversions newState:29.2461538461538: rounded:30: stateTrans:30:
2017.02.07 17:51:16 4: SOMFY_TimedUpdate: rollBuero -> update state in 4.83 sec
2017.02.07 17:51:16 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486486279.03811
2017.02.07 17:51:16 5: SOMFY_TimedUpdate DONE
2017.02.07 17:51:19 4: SOMFY_TimedUpdate
2017.02.07 17:51:19 5: SOMFY_TimedUpdate : pos before convert so far : 29.2461538461538
2017.02.07 17:51:19 5: SOMFY_TimedUpdate : pos so far : 78.6153846153846
2017.02.07 17:51:19 5: SOMFY_TimedUpdate : delta time : 3.01 new rounde pos (rounded): 111.5
2017.02.07 17:51:19 4: SOMFY_UpdateState: rollBuero enter with newState:111.5: updatestate:200: move:on:
2017.02.07 17:51:19 4: SOMFY_UpdateState: rollBuero after conversions newState:8.85: rounded:10: stateTrans:down:
2017.02.07 17:51:19 4: SOMFY_TimedUpdate: rollBuero -> update state in 1.82 sec
2017.02.07 17:51:19 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486486280.86856
2017.02.07 17:51:19 5: SOMFY_TimedUpdate DONE
2017.02.07 17:51:20 4: SOMFY_TimedUpdate
2017.02.07 17:51:20 5: SOMFY_TimedUpdate : pos before convert so far : 8.85
2017.02.07 17:51:20 5: SOMFY_TimedUpdate : pos so far : 111.5
2017.02.07 17:51:20 5: SOMFY_TimedUpdate : delta time : 1.81 new rounde pos (rounded): 200
2017.02.07 17:51:20 4: SOMFY_UpdateState: rollBuero enter with newState:200: updatestate:<undef>: move:stop:
2017.02.07 17:51:20 4: SOMFY_UpdateState: rollBuero after conversions newState:0: rounded:0: stateTrans:closed:
2017.02.07 17:51:20 5: SOMFY_TimedUpdate DONE
2017.02.07 17:51:51 4: SOMFY_set: rollBuero Inverse before cmd:pos: arg1:50: pos:0:
2017.02.07 17:51:51 4: SOMFY_set: rollBuero Inverse after cmd:pos: arg1:55.5555555555556: pos:200:
2017.02.07 17:51:51 4: SOMFY_set: rollBuero -> entering with mode :send: cmd :pos: arg1 :55.5555555555556: pos :200:
2017.02.07 17:51:51 4: SOMFY_set: handled command pos --> move :off: newState :200:
2017.02.07 17:51:51 5: SOMFY_set: handled for drive/udpate: updateState :55.5555555555556: drivet :9.22222222222222: updatet :0:
2017.02.07 17:51:51 4: SOMFY_UpdateState: rollBuero enter with newState:200: updatestate:55.5555555555556: move:off:
2017.02.07 17:51:51 4: SOMFY_UpdateState: rollBuero after conversions newState:0: rounded:0: stateTrans:closed:
2017.02.07 17:51:51 4: SOMFY_sendCommand: rollBuero -> cmd :off:
2017.02.07 17:51:51 5: SOMFY_sendCommand: rollBuero -> message :sAC2000FC000059:
2017.02.07 17:51:51 4: SOMFY_set: rollBuero -> stopping in 9.22222222222222 sec
2017.02.07 17:51:51 4: SOMFY_set: rollBuero Inverse before cmd:off: arg1:: pos:0:
2017.02.07 17:51:51 4: SOMFY_set: rollBuero Inverse after cmd:off: arg1:: pos:200:
2017.02.07 17:51:51 4: SOMFY_set: rollBuero -> entering with mode :virtual: cmd :off: arg1 :: pos :200:
2017.02.07 17:51:51 4: SOMFY_set: handled command off --> move :off: newState :194:
2017.02.07 17:51:51 5: SOMFY_set: handled for drive/udpate: updateState :0: drivet :0: updatet :16.79:
2017.02.07 17:51:51 4: SOMFY_UpdateState: rollBuero enter with newState:194: updatestate:0: move:off:
2017.02.07 17:51:51 4: SOMFY_UpdateState: rollBuero after conversions newState:0.6: rounded:0: stateTrans:closed:
2017.02.07 17:51:51 4: SOMFY_set: rollBuero -> update state in 16.79 sec
2017.02.07 17:51:52 1: usb create starting
2017.02.07 17:51:52 3: Probing CUL device /dev/ttyAMA0
2017.02.07 17:51:53 3: Probing TCM_ESP3 device /dev/ttyAMA0
2017.02.07 17:51:53 3: Probing FRM device /dev/ttyAMA0
2017.02.07 17:51:58 1: usb create end
2017.02.07 17:51:58 3: CUL_0: Unknown code YsAC2B00FC590000, help me!
2017.02.07 17:51:58 4: SOMFY_TimedUpdate
2017.02.07 17:51:58 5: SOMFY_TimedUpdate : pos before convert so far : 0.6
2017.02.07 17:51:58 5: SOMFY_TimedUpdate : pos so far : 194
2017.02.07 17:51:58 5: SOMFY_TimedUpdate : delta time : 6.96 new rounde pos (rounded): 70.4285714285714
2017.02.07 17:51:58 4: SOMFY_UpdateState: rollBuero enter with newState:70.4285714285714: updatestate:0: move:off:
2017.02.07 17:51:58 4: SOMFY_UpdateState: rollBuero after conversions newState:36.6142857142857: rounded:40: stateTrans:40:
2017.02.07 17:51:58 4: SOMFY_TimedUpdate: rollBuero -> update state in 9.83 sec
2017.02.07 17:51:58 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486486321.5745
2017.02.07 17:51:58 5: SOMFY_TimedUpdate DONE
2017.02.07 17:52:01 4: SOMFY_TimedUpdate
2017.02.07 17:52:01 5: SOMFY_TimedUpdate : pos before convert so far : 36.6142857142857
2017.02.07 17:52:01 5: SOMFY_TimedUpdate : pos so far : 70.4285714285714
2017.02.07 17:52:01 5: SOMFY_TimedUpdate : delta time : 2.99 new rounde pos (rounded): 49.0714285714286
2017.02.07 17:52:01 4: SOMFY_UpdateState: rollBuero enter with newState:49.0714285714286: updatestate:0: move:off:
2017.02.07 17:52:01 4: SOMFY_UpdateState: rollBuero after conversions newState:55.8357142857143: rounded:60: stateTrans:60:
2017.02.07 17:52:01 4: SOMFY_TimedUpdate: rollBuero -> update state in 6.84 sec
2017.02.07 17:52:01 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486486324.56827
2017.02.07 17:52:01 5: SOMFY_TimedUpdate DONE
2017.02.07 17:52:04 4: SOMFY_TimedUpdate
2017.02.07 17:52:04 5: SOMFY_TimedUpdate : pos before convert so far : 55.8357142857143
2017.02.07 17:52:04 5: SOMFY_TimedUpdate : pos so far : 49.0714285714286
2017.02.07 17:52:04 5: SOMFY_TimedUpdate : delta time : 3.00 new rounde pos (rounded): 27.6428571428571
2017.02.07 17:52:04 4: SOMFY_UpdateState: rollBuero enter with newState:27.6428571428571: updatestate:0: move:off:
2017.02.07 17:52:04 4: SOMFY_UpdateState: rollBuero after conversions newState:75.1214285714286: rounded:80: stateTrans:80:
2017.02.07 17:52:04 4: SOMFY_TimedUpdate: rollBuero -> update state in 3.84 sec
2017.02.07 17:52:04 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486486327.56718
2017.02.07 17:52:04 5: SOMFY_TimedUpdate DONE
2017.02.07 17:52:07 4: SOMFY_TimedUpdate
2017.02.07 17:52:07 5: SOMFY_TimedUpdate : pos before convert so far : 75.1214285714286
2017.02.07 17:52:07 5: SOMFY_TimedUpdate : pos so far : 27.6428571428571
2017.02.07 17:52:07 5: SOMFY_TimedUpdate : delta time : 2.99 new rounde pos (rounded): 6.28571428571427
2017.02.07 17:52:07 4: SOMFY_UpdateState: rollBuero enter with newState:6.28571428571427: updatestate:0: move:off:
2017.02.07 17:52:07 4: SOMFY_UpdateState: rollBuero after conversions newState:94.3428571428572: rounded:90: stateTrans:90:
2017.02.07 17:52:07 4: SOMFY_TimedUpdate: rollBuero -> update state in 0.849999999999998 sec
2017.02.07 17:52:07 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486486328.41001
2017.02.07 17:52:07 5: SOMFY_TimedUpdate DONE
2017.02.07 17:52:08 4: SOMFY_TimedUpdate
2017.02.07 17:52:08 5: SOMFY_TimedUpdate : pos before convert so far : 94.3428571428572
2017.02.07 17:52:08 5: SOMFY_TimedUpdate : pos so far : 6.28571428571427
2017.02.07 17:52:08 5: SOMFY_TimedUpdate : delta time : 0.84 new rounde pos (rounded): 0.285714285714271
2017.02.07 17:52:08 4: SOMFY_UpdateState: rollBuero enter with newState:0: updatestate:<undef>: move:stop:
2017.02.07 17:52:08 4: SOMFY_UpdateState: rollBuero after conversions newState:100: rounded:100: stateTrans:open:
2017.02.07 17:52:08 5: SOMFY_TimedUpdate DONE
und das dev log
2017-02-07_17:47:04 rollBuero closed
2017-02-07_17:47:04 rollBuero position: 0
2017-02-07_17:47:04 rollBuero exact: 0.6
2017-02-07_17:47:04 rollBuero 40
2017-02-07_17:47:04 rollBuero position: 40
2017-02-07_17:47:04 rollBuero exact: 36.6142857142857
2017-02-07_17:47:07 rollBuero 60
2017-02-07_17:47:07 rollBuero position: 60
2017-02-07_17:47:07 rollBuero exact: 55.8357142857143
2017-02-07_17:47:10 rollBuero 80
2017-02-07_17:47:10 rollBuero position: 80
2017-02-07_17:47:10 rollBuero exact: 75.0571428571429
2017-02-07_17:47:13 rollBuero 90
2017-02-07_17:47:13 rollBuero position: 90
2017-02-07_17:47:13 rollBuero exact: 94.2785714285715
2017-02-07_17:47:14 rollBuero open
2017-02-07_17:47:14 rollBuero position: 100
2017-02-07_17:47:14 rollBuero exact: 100
2017-02-07_17:51:13 rollBuero open
2017-02-07_17:51:13 rollBuero position: 100
2017-02-07_17:51:13 rollBuero exact: 98.2
2017-02-07_17:51:13 rollBuero 50
2017-02-07_17:51:13 rollBuero position: 50
2017-02-07_17:51:13 rollBuero exact: 49.9461538461538
2017-02-07_17:51:16 rollBuero 30
2017-02-07_17:51:16 rollBuero position: 30
2017-02-07_17:51:16 rollBuero exact: 29.2461538461538
2017-02-07_17:51:19 rollBuero down
2017-02-07_17:51:19 rollBuero position: 10
2017-02-07_17:51:19 rollBuero exact: 8.85
2017-02-07_17:51:20 rollBuero closed
2017-02-07_17:51:20 rollBuero position: 0
2017-02-07_17:51:20 rollBuero exact: 0
2017-02-07_17:51:58 rollBuero closed
2017-02-07_17:51:58 rollBuero position: 0
2017-02-07_17:51:58 rollBuero exact: 0.6
2017-02-07_17:51:58 rollBuero 40
2017-02-07_17:51:58 rollBuero position: 40
2017-02-07_17:51:58 rollBuero exact: 36.6142857142857
2017-02-07_17:52:01 rollBuero 60
2017-02-07_17:52:01 rollBuero position: 60
2017-02-07_17:52:01 rollBuero exact: 55.8357142857143
2017-02-07_17:52:04 rollBuero 80
2017-02-07_17:52:04 rollBuero position: 80
2017-02-07_17:52:04 rollBuero exact: 75.1214285714286
2017-02-07_17:52:07 rollBuero 90
2017-02-07_17:52:07 rollBuero position: 90
2017-02-07_17:52:07 rollBuero exact: 94.3428571428572
2017-02-07_17:52:08 rollBuero open
2017-02-07_17:52:08 rollBuero position: 100
2017-02-07_17:52:08 rollBuero exact: 100
mal so geraten
2017.02.07 17:47:13 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486486034.3744
soll das die zeit sein wann gestoptwerden soll in sekunden ?
das wären dann ca 17,5 tausend tage. Kalender stapel. :D
Dein Cul hat ein Problem:
2017.02.07 17:51:52 1: usb create starting
2017.02.07 17:51:52 3: Probing CUL device /dev/ttyAMA0
2017.02.07 17:51:53 3: Probing TCM_ESP3 device /dev/ttyAMA0
2017.02.07 17:51:53 3: Probing FRM device /dev/ttyAMA0
2017.02.07 17:51:58 1: usb create end
2017.02.07 17:51:58 3: CUL_0: Unknown code YsAC2B00FC590000, help me!
Es sieht so aus, als ob der sich ständig ab und anmeldet.
Das scheint der nur zu machen wenn ich an die shutter ein Signal sende.
Der aktuell letzte Eintrag im log ist von gestern 19:51 .
Hm evtl ist das Netzteil ausgelaugt , mal schauen.
Tante edith: warum empfängt der cul sich selbst. 000059 hab ich im Modul für die def angelegt. Das ist nen cul v3 mit a-cfw. Der sollte doch nur senden.
Und der fhemduino empfangen.
Gesendet von iPad mit Tapatalk
also ich habe die anderen usb anschlüsse freigemacht, war sowieso geplant.
und der cul meldet sich nicht mehr an und ab, also zuviel am saugen.
dennoch macht der das nicht, die zeit für den stop berechnet der scheinbar richtig, dennoch klappt das nicht, denn die zeit ist der logic nach zu lange in der laufzeit. denn die startzeit wird falsch gepunktet. ^^
habe mal nen screen drum gefaltet. der erste ist nur eine normale fahrt, der zweitr mit 7.22222 sec ist auf pos 50.
Zitat von: BlackStone am 09 Februar 2017, 17:59:02
also ich habe die anderen usb anschlüsse freigemacht, war sowieso geplant.
und der cul meldet sich nicht mehr an und ab, also zuviel am saugen.
dennoch macht der das nicht, die zeit für den stop berechnet der scheinbar richtig, dennoch klappt das nicht, denn die zeit ist der logic nach zu lange in der laufzeit. denn die startzeit wird falsch gepunktet. ^^
habe mal nen screen drum gefaltet. der erste ist nur eine normale fahrt, der zweitr mit 7.22222 sec ist auf pos 50.
Die Startzeit ist völlig richtig und nicht "falsch gepunktet" die startzeit ist eine Uhrzeit/Timestamp (als Angabe in Sekunden). Das sind aber eigentlich beides komplett interne Werte für die Fahrzeit und nichts woraus man etwas ableiten könnte.
Das bringt so nichts, wenn der CUL jetzt tut, dann mach doch nochmal denselben Log wie oben schonmal angefordert.
Ich habe mir den Log von oben nochmals angeschaut und nach dem "pos 50" wird direkt ein kommando "off" verarbeitet? Gibt es da noch etwas was reinpfuscht? Hast DU nur den CUL oder auch andere Empfänger?
Zitat von: viegener am 09 Februar 2017, 19:13:07
Die Startzeit ist völlig richtig und nicht "falsch gepunktet" die startzeit ist eine Uhrzeit/Timestamp (als Angabe in Sekunden). Das sind aber eigentlich beides komplett interne Werte für die Fahrzeit und nichts woraus man etwas ableiten könnte.
Das bringt so nichts, wenn der CUL jetzt tut, dann mach doch nochmal denselben Log wie oben schonmal angefordert.
Ich habe mir den Log von oben nochmals angeschaut und nach dem "pos 50" wird direkt ein kommando "off" verarbeitet? Gibt es da noch etwas was reinpfuscht? Hast DU nur den CUL oder auch andere Empfänger?
Noch konkreter: Kann es sein, dass DU einen fhemduino hast und die Adresse Deines Somfy-Devices in FHEM auch per FHEMDuino an den Somfy-Device gebunden hast? Oder setzt Du eine modifizierte SOMFY.PM ein ?
ich nutze einen fhemduino und einen cul v3, und die module sind alle aus dem svn also wird automatisch mit upgedatet und nix verändert an den dateien.
fhemduino:
Internals:
CMDS VifdhtRq
Clients :IT:CUL_TX:OREGON:FHEMduino_Env:FHEMduino_EZ6:FHEMduino_Oregon:FHEMduino_PT2262:FHEMduino_FA20RF:FHEMduino_TCM:FHEMduino_HX:FHEMduino_DCF77:FHEMduino_Gas:FHEMduino_SomfyR:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02MI1J-if00-port0@9600
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02MI1J-if00-port0@9600
FD 11
FHEMduino_MSGCNT 93
FHEMduino_TIME 2017-02-09 20:21:46
NAME FHEMduino
NR 23
PARTIAL
RAWMSG Ys af 40 011f 590000
STATE Initialized
TYPE FHEMduino
VERSION V 2.3v FHEMduino - compiled at Jun 28 215 2:31:02
.clientArray:
FHEMduino_PT2262
FHEMduino_SomfyR
Matchlist:
10:FHEMduino_DCF77 D...............$
11:OREGON ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
12:FHEMduino_Gas G...........$
13:FHEMduino_SomfyR Ys .. .. .... ......$
1:IT ^i......$
2:CUL_TX ^TX..........
3:FHEMduino_Env W.*$
4:FHEMduino_EZ6 E...........$
5:FHEMduino_Oregon OSV2:.*$
6:FHEMduino_PT2262 IR.*$
7:FHEMduino_FA20RF F............$
8:FHEMduino_TCM M.....$
9:FHEMduino_HX H...$
Readings:
2016-11-27 16:48:02 FAParms No answer
2017-02-09 18:17:41 cmds V i f d h t R q
2017-01-03 17:27:32 raw isF000FFFFF0317
2017-02-09 18:17:38 state opened
2016-11-27 17:12:00 uptime 0 00:00:24
Attributes:
flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
verbose 1
CUL:
nternals:
CMDS ABbCeFGhiKkLlMmNRTtUuVWXxYZ
CUL_0_MSGCNT 1101
CUL_0_TIME 2017-02-09 20:30:00
Clients :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:
DEF /dev/ttyACM0@9600 1034
DeviceName /dev/ttyACM0@9600
FD 10
FHTID 1034
NAME CUL_0
NR 21
NR_CMD_LAST_H 3
PARTIAL
RAWMSG A14D5845E2EAAC200000080C202000000000008D80237
RSSI -46.5
STATE Initialized
TYPE CUL
VERSION V 1.67 CUL868
initString X21
Ar
.clientArray:
CUL_HM
Matchlist:
1:CUL_HM ^A....................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
Readings:
2017-02-09 18:17:38 cmds A B b C e F G h i K k L l M m N R T t U u V W X x Y Z
2017-02-09 20:30:00 state Initialized
XMIT_TIME:
1486664632.48939
1486664884.56104
1486668214.43095
Helper:
30cbb9:
QUEUE:
363bb4:
QUEUE:
Attributes:
addvaltrigger 1
hmId 2BC9D1
rfmode HomeMatic
room CUL_HM
Internals:
ADDRESS 63C3AE
DEF 63C3AE
FHEMduino_MSGCNT 4
FHEMduino_RAWMSG Ys a9 20 0299 aec363
FHEMduino_TIME 2017-02-09 20:14:56
IODev FHEMduino
LASTInputDev FHEMduino
MSGCNT 4
NAME fb_Roll_Buero
NR 24
STATE 20
TYPE FHEMduino_SomfyR
lastMsg Ys a9 20 0299 aec363
Readings:
2017-02-09 20:14:55 command 20
2017-02-09 20:14:55 state 20
Attributes:
IODev FHEMduino
rawDevice 000059
room FHEMduino_SomfyR
Internals:
.eventMapCmd Auf:noArg Zu:noArg Stop:noArg Sonne:noArg
ADDRESS 000059
DEF 000059
IODev CUL_0
NAME rollBuero
NR 50
STATE closed
TYPE SOMFY
move stop
Code:
1 000059
Readings:
2017-02-09 20:21:45 enc_key A0
2017-02-09 20:22:00 exact 200
2017-01-03 17:13:51 parsestate on
2017-02-09 20:22:00 position 200
2017-02-09 20:21:45 rolling_code 0120
2017-02-09 20:22:00 state closed
Attributes:
IODev CUL_0
devStateIcon open:fts_shutter_10 10:fts_shutter_10 20:fts_shutter_20 30:fts_shutter_30 40:fts_shutter_40 50:fts_shutter_50 60:fts_shutter_60 70:fts_shutter_70 80:fts_shutter_80 90:fts_shutter_90 down:fts_shutter_100 closed:fts_shutter_100
drive-down-time-to-100 13
drive-down-time-to-close 15
drive-up-time-to-100 3
drive-up-time-to-open 17
eventMap off:Auf on:Zu stop:Stop go-my:Sonne
model somfyshutter
positionInverse 0
room Rolladen
verbose 5
webCmd Auf: Stop: Zu:Sonne
2017.02.09 20:21:16 4: SOMFY_set: rollBuero -> entering with mode :send: cmd :off: arg1 :: pos :200:
2017.02.09 20:21:16 4: SOMFY_set: handled command off --> move :off: newState :200:
2017.02.09 20:21:16 5: SOMFY_set: handled for drive/udpate: updateState :0: drivet :0: updatet :17:
2017.02.09 20:21:16 4: SOMFY_UpdateState: rollBuero enter with newState:200: updatestate:0: move:off:
2017.02.09 20:21:16 4: SOMFY_UpdateState: rollBuero after conversions newState:200: rounded:200: stateTrans:closed:
2017.02.09 20:21:16 4: SOMFY_sendCommand: rollBuero -> cmd :off:
2017.02.09 20:21:16 5: SOMFY_sendCommand: rollBuero -> message :sAE20011E000059:
2017.02.09 20:21:16 4: SOMFY_set: rollBuero -> update state in 17 sec
2017.02.09 20:21:16 4: SOMFY_set: rollBuero -> entering with mode :virtual: cmd :off: arg1 :: pos :200:
2017.02.09 20:21:16 4: SOMFY_set: handled command off --> move :off: newState :188:
2017.02.09 20:21:16 5: SOMFY_set: handled for drive/udpate: updateState :0: drivet :0: updatet :16.65:
2017.02.09 20:21:16 4: SOMFY_UpdateState: rollBuero enter with newState:188: updatestate:0: move:off:
2017.02.09 20:21:16 4: SOMFY_UpdateState: rollBuero after conversions newState:188: rounded:150: stateTrans:down:
2017.02.09 20:21:16 4: SOMFY_set: rollBuero -> update state in 16.65 sec
2017.02.09 20:21:17 1: usb create starting
2017.02.09 20:21:17 3: Probing CUL device /dev/ttyAMA0
2017.02.09 20:21:17 3: Probing TCM_ESP3 device /dev/ttyAMA0
2017.02.09 20:21:17 3: Probing FRM device /dev/ttyAMA0
2017.02.09 20:21:23 1: usb create end
2017.02.09 20:21:23 3: CUL_0: Unknown code YsAE24011E590000, help me!
2017.02.09 20:21:23 4: SOMFY_TimedUpdate
2017.02.09 20:21:23 5: SOMFY_TimedUpdate : pos so far : 188
2017.02.09 20:21:23 5: SOMFY_TimedUpdate : delta time : 6.78 new rounde pos (rounded): 70.4285714285714
2017.02.09 20:21:23 4: SOMFY_UpdateState: rollBuero enter with newState:70.4285714285714: updatestate:0: move:off:
2017.02.09 20:21:23 4: SOMFY_UpdateState: rollBuero after conversions newState:70.4285714285714: rounded:70: stateTrans:70:
2017.02.09 20:21:23 4: SOMFY_TimedUpdate: rollBuero -> update state in 9.87 sec
2017.02.09 20:21:23 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486668086.23194
2017.02.09 20:21:23 5: SOMFY_TimedUpdate DONE
2017.02.09 20:21:26 4: SOMFY_TimedUpdate
2017.02.09 20:21:26 5: SOMFY_TimedUpdate : pos so far : 70.4285714285714
2017.02.09 20:21:26 5: SOMFY_TimedUpdate : delta time : 2.99 new rounde pos (rounded): 49.0714285714286
2017.02.09 20:21:26 4: SOMFY_UpdateState: rollBuero enter with newState:49.0714285714286: updatestate:0: move:off:
2017.02.09 20:21:26 4: SOMFY_UpdateState: rollBuero after conversions newState:49.0714285714286: rounded:50: stateTrans:50:
2017.02.09 20:21:26 4: SOMFY_TimedUpdate: rollBuero -> update state in 6.88 sec
2017.02.09 20:21:26 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486668089.22582
2017.02.09 20:21:26 5: SOMFY_TimedUpdate DONE
2017.02.09 20:21:29 4: SOMFY_TimedUpdate
2017.02.09 20:21:29 5: SOMFY_TimedUpdate : pos so far : 49.0714285714286
2017.02.09 20:21:29 5: SOMFY_TimedUpdate : delta time : 2.99 new rounde pos (rounded): 27.7142857142857
2017.02.09 20:21:29 4: SOMFY_UpdateState: rollBuero enter with newState:27.7142857142857: updatestate:0: move:off:
2017.02.09 20:21:29 4: SOMFY_UpdateState: rollBuero after conversions newState:27.7142857142857: rounded:30: stateTrans:30:
2017.02.09 20:21:29 4: SOMFY_TimedUpdate: rollBuero -> update state in 3.89 sec
2017.02.09 20:21:29 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486668092.21979
2017.02.09 20:21:29 5: SOMFY_TimedUpdate DONE
2017.02.09 20:21:32 4: SOMFY_TimedUpdate
2017.02.09 20:21:32 5: SOMFY_TimedUpdate : pos so far : 27.7142857142857
2017.02.09 20:21:32 5: SOMFY_TimedUpdate : delta time : 2.99 new rounde pos (rounded): 6.35714285714284
2017.02.09 20:21:32 4: SOMFY_UpdateState: rollBuero enter with newState:6.35714285714284: updatestate:0: move:off:
2017.02.09 20:21:32 4: SOMFY_UpdateState: rollBuero after conversions newState:6.35714285714284: rounded:10: stateTrans:10:
2017.02.09 20:21:32 4: SOMFY_TimedUpdate: rollBuero -> update state in 0.899999999999997 sec
2017.02.09 20:21:32 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486668093.11372
2017.02.09 20:21:32 5: SOMFY_TimedUpdate DONE
2017.02.09 20:21:33 4: SOMFY_TimedUpdate
2017.02.09 20:21:33 5: SOMFY_TimedUpdate : pos so far : 6.35714285714284
2017.02.09 20:21:33 5: SOMFY_TimedUpdate : delta time : 0.89 new rounde pos (rounded): 0
2017.02.09 20:21:33 4: SOMFY_UpdateState: rollBuero enter with newState:0: updatestate:<undef>: move:stop:
2017.02.09 20:21:33 4: SOMFY_UpdateState: rollBuero after conversions newState:0: rounded:0: stateTrans:open:
2017.02.09 20:21:33 5: SOMFY_TimedUpdate DONE
2017.02.09 20:21:45 4: SOMFY_set: rollBuero -> entering with mode :send: cmd :pos: arg1 :50: pos :0:
2017.02.09 20:21:45 4: SOMFY_set: handled command pos --> move :on: newState :0:
2017.02.09 20:21:45 5: SOMFY_set: handled for drive/udpate: updateState :50: drivet :6.5: updatet :0:
2017.02.09 20:21:45 4: SOMFY_UpdateState: rollBuero enter with newState:0: updatestate:50: move:on:
2017.02.09 20:21:45 4: SOMFY_UpdateState: rollBuero after conversions newState:0: rounded:0: stateTrans:open:
2017.02.09 20:21:45 4: SOMFY_sendCommand: rollBuero -> cmd :on:
2017.02.09 20:21:45 5: SOMFY_sendCommand: rollBuero -> message :sAF40011F000059:
2017.02.09 20:21:45 4: SOMFY_set: rollBuero -> stopping in 6.5 sec
2017.02.09 20:21:45 4: SOMFY_set: rollBuero -> entering with mode :virtual: cmd :on: arg1 :: pos :0:
2017.02.09 20:21:45 4: SOMFY_set: handled command on --> move :on: newState :2:
2017.02.09 20:21:45 5: SOMFY_set: handled for drive/udpate: updateState :200: drivet :0: updatet :14.79:
2017.02.09 20:21:45 4: SOMFY_UpdateState: rollBuero enter with newState:2: updatestate:200: move:on:
2017.02.09 20:21:45 4: SOMFY_UpdateState: rollBuero after conversions newState:2: rounded:0: stateTrans:open:
2017.02.09 20:21:45 4: SOMFY_set: rollBuero -> update state in 14.79 sec
2017.02.09 20:21:46 1: usb create starting
2017.02.09 20:21:47 3: Probing CUL device /dev/ttyAMA0
2017.02.09 20:21:47 3: Probing TCM_ESP3 device /dev/ttyAMA0
2017.02.09 20:21:47 3: Probing FRM device /dev/ttyAMA0
2017.02.09 20:21:52 1: usb create end
2017.02.09 20:21:52 3: CUL_0: Unknown code YsAF42011F590000, help me!
2017.02.09 20:21:52 4: SOMFY_TimedUpdate
2017.02.09 20:21:52 5: SOMFY_TimedUpdate : pos so far : 2
2017.02.09 20:21:52 5: SOMFY_TimedUpdate : delta time : 6.92 new rounde pos (rounded): 55.2307692307692
2017.02.09 20:21:52 4: SOMFY_UpdateState: rollBuero enter with newState:55.2307692307692: updatestate:200: move:on:
2017.02.09 20:21:52 4: SOMFY_UpdateState: rollBuero after conversions newState:55.2307692307692: rounded:60: stateTrans:60:
2017.02.09 20:21:52 4: SOMFY_TimedUpdate: rollBuero -> update state in 7.87 sec
2017.02.09 20:21:52 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486668115.76246
2017.02.09 20:21:52 5: SOMFY_TimedUpdate DONE
2017.02.09 20:21:55 4: SOMFY_TimedUpdate
2017.02.09 20:21:55 5: SOMFY_TimedUpdate : pos so far : 55.2307692307692
2017.02.09 20:21:55 5: SOMFY_TimedUpdate : delta time : 2.99 new rounde pos (rounded): 78.2307692307692
2017.02.09 20:21:55 4: SOMFY_UpdateState: rollBuero enter with newState:78.2307692307692: updatestate:200: move:on:
2017.02.09 20:21:55 4: SOMFY_UpdateState: rollBuero after conversions newState:78.2307692307692: rounded:80: stateTrans:80:
2017.02.09 20:21:55 4: SOMFY_TimedUpdate: rollBuero -> update state in 4.88 sec
2017.02.09 20:21:55 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486668118.75676
2017.02.09 20:21:55 5: SOMFY_TimedUpdate DONE
2017.02.09 20:21:58 4: SOMFY_TimedUpdate
2017.02.09 20:21:58 5: SOMFY_TimedUpdate : pos so far : 78.2307692307692
2017.02.09 20:21:58 5: SOMFY_TimedUpdate : delta time : 2.99 new rounde pos (rounded): 108
2017.02.09 20:21:58 4: SOMFY_UpdateState: rollBuero enter with newState:108: updatestate:200: move:on:
2017.02.09 20:21:58 4: SOMFY_UpdateState: rollBuero after conversions newState:108: rounded:150: stateTrans:down:
2017.02.09 20:21:58 4: SOMFY_TimedUpdate: rollBuero -> update state in 1.89 sec
2017.02.09 20:21:58 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486668120.64087
2017.02.09 20:21:58 5: SOMFY_TimedUpdate DONE
2017.02.09 20:22:00 4: SOMFY_TimedUpdate
2017.02.09 20:22:00 5: SOMFY_TimedUpdate : pos so far : 108
2017.02.09 20:22:00 5: SOMFY_TimedUpdate : delta time : 1.88 new rounde pos (rounded): 200
2017.02.09 20:22:00 4: SOMFY_UpdateState: rollBuero enter with newState:200: updatestate:<undef>: move:stop:
2017.02.09 20:22:00 4: SOMFY_UpdateState: rollBuero after conversions newState:200: rounded:200: stateTrans:closed:
2017.02.09 20:22:00 5: SOMFY_TimedUpdate DONE
Der übersicht wegen mal extra post.
mir ist grade was komisches aufgefallen,
der cul arbeitet sauber, keine probleme mit der Fußbodenheizung. den homatic wandthermostaten usw.
nur im log tauch genau für die somfys ne reihe iodev fehler auf.
2017.02.09 21:13:25 1: Including ./log/fhem.save
2017.02.09 21:13:26 3: No I/O device found for rollBuero
2017.02.09 21:13:26 3: No I/O device found for rollHauptbad
2017.02.09 21:13:26 3: No I/O device found for rollEsszimmer
2017.02.09 21:13:26 3: No I/O device found for rollVorrat
2017.02.09 21:13:26 3: No I/O device found for rollWohnzimmer
2017.02.09 21:13:26 3: No I/O device found for rollKueche
2017.02.09 21:13:26 3: No I/O device found for rollGaesteBad
2017.02.09 21:13:26 3: No I/O device found for rollWohnzimmer_Tuer
2017.02.09 21:13:26 3: No I/O device found for rollSchlafz_links
2017.02.09 21:13:26 3: No I/O device found for rollSchlafz_rechts
für die fernbedinungsn habe ich immer ein fb_ davor so das es ausgeschlossensein kann das das vom fhemduino kommt.
@blockstone: In deinem log stehen weiter die selben Meldungen zum an/abmelden des culs - macht keine Sinn einen Fehler zu suchen, wenn der cul nicht sauber funktioniert:
2017.02.09 20:21:45 4: SOMFY_set: rollBuero -> update state in 14.79 sec
2017.02.09 20:21:46 1: usb create starting
2017.02.09 20:21:47 3: Probing CUL device /dev/ttyAMA0
2017.02.09 20:21:47 3: Probing TCM_ESP3 device /dev/ttyAMA0
2017.02.09 20:21:47 3: Probing FRM device /dev/ttyAMA0
2017.02.09 20:21:52 1: usb create end
2017.02.09 20:21:52 3: CUL_0: Unknown code YsAF42011F590000, help me!
Warum taucht das nur beim Somfy auf und nur dann ?
hinzu kommt das dort kein abmelden vorhanden ist, dann wäre ein vermerk auf disabled oder so da.
2017.02.09 22:35:48 4: SOMFY_UpdateState: rollBuero enter with newState:178: updatestate:0: move:off:
2017.02.09 22:35:48 4: SOMFY_UpdateState: rollBuero after conversions newState:178: rounded:150: stateTrans:down:
2017.02.09 22:35:48 4: SOMFY_set: rollBuero -> update state in 16.36 sec
2017.02.09 22:35:48 1: usb create starting
2017.02.09 22:35:49 3: Probing CUL device /dev/ttyAMA0
2017.02.09 22:35:49 3: Probing TCM_ESP3 device /dev/ttyAMA0
2017.02.09 22:35:49 3: Probing FRM device /dev/ttyAMA0
2017.02.09 22:35:54 1: usb create end
2017.02.09 22:35:54 3: CUL_0: Unknown code YsA1270121590000, help me!
2017.02.09 22:35:54 4: SOMFY_TimedUpdate
2017.02.09 22:35:54 5: SOMFY_TimedUpdate : pos so far : 178
2017.02.09 22:35:54 5: SOMFY_TimedUpdate : delta time : 6.51 new rounde pos (rounded): 70.2142857142857
2017.02.09 22:35:54 4: SOMFY_UpdateState: rollBuero enter with newState:70.2142857142857: updatestate:0: move:off:
2017.02.09 22:35:54 4: SOMFY_UpdateState: rollBuero after conversions newState:70.2142857142857: rounded:70: stateTrans:70:
2017.02.09 22:35:54 4: SOMFY_TimedUpdate: rollBuero -> update state in 9.85 sec
2017.02.09 22:35:54 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486676157.83429
2017.02.09 22:35:54 5: SOMFY_TimedUpdate DONE
2017.02.09 22:35:57 4: SOMFY_TimedUpdate
2017.02.09 22:35:57 5: SOMFY_TimedUpdate : pos so far : 70.2142857142857
2017.02.09 22:35:57 5: SOMFY_TimedUpdate : delta time : 2.99 new rounde pos (rounded): 48.8571428571429
2017.02.09 22:35:57 4: SOMFY_UpdateState: rollBuero enter with newState:48.8571428571429: updatestate:0: move:off:
2017.02.09 22:35:57 4: SOMFY_UpdateState: rollBuero after conversions newState:48.8571428571429: rounded:50: stateTrans:50:
2017.02.09 22:35:57 4: SOMFY_TimedUpdate: rollBuero -> update state in 6.86 sec
2017.02.09 22:35:57 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486676160.82688
2017.02.09 22:35:57 5: SOMFY_TimedUpdate DONE
2017.02.09 22:36:00 4: SOMFY_TimedUpdate
2017.02.09 22:36:00 5: SOMFY_TimedUpdate : pos so far : 48.8571428571429
2017.02.09 22:36:00 5: SOMFY_TimedUpdate : delta time : 2.99 new rounde pos (rounded): 27.5
2017.02.09 22:36:00 4: SOMFY_UpdateState: rollBuero enter with newState:27.5: updatestate:0: move:off:
2017.02.09 22:36:00 4: SOMFY_UpdateState: rollBuero after conversions newState:27.5: rounded:30: stateTrans:30:
2017.02.09 22:36:00 4: SOMFY_TimedUpdate: rollBuero -> update state in 3.87 sec
2017.02.09 22:36:00 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486676163.81953
2017.02.09 22:36:00 5: SOMFY_TimedUpdate DONE
2017.02.09 22:36:03 4: SOMFY_TimedUpdate
2017.02.09 22:36:03 5: SOMFY_TimedUpdate : pos so far : 27.5
2017.02.09 22:36:03 5: SOMFY_TimedUpdate : delta time : 2.99 new rounde pos (rounded): 6.14285714285715
2017.02.09 22:36:03 4: SOMFY_UpdateState: rollBuero enter with newState:6.14285714285715: updatestate:0: move:off:
2017.02.09 22:36:03 4: SOMFY_UpdateState: rollBuero after conversions newState:6.14285714285715: rounded:10: stateTrans:10:
2017.02.09 22:36:03 4: SOMFY_TimedUpdate: rollBuero -> update state in 0.879999999999999 sec
2017.02.09 22:36:03 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486676164.69227
2017.02.09 22:36:03 5: SOMFY_TimedUpdate DONE
2017.02.09 22:36:04 4: SOMFY_TimedUpdate
2017.02.09 22:36:04 5: SOMFY_TimedUpdate : pos so far : 6.14285714285715
2017.02.09 22:36:04 5: SOMFY_TimedUpdate : delta time : 0.87 new rounde pos (rounded): 0
2017.02.09 22:36:04 4: SOMFY_UpdateState: rollBuero enter with newState:0: updatestate:<undef>: move:stop:
2017.02.09 22:36:04 4: SOMFY_UpdateState: rollBuero after conversions newState:0: rounded:0: stateTrans:open:
2017.02.09 22:36:04 5: SOMFY_TimedUpdate DONE
2017.02.09 22:36:24 4: SOMFY_set: rollBuero -> entering with mode :send: cmd :pos: arg1 :50: pos :0:
2017.02.09 22:36:24 4: SOMFY_set: handled command pos --> move :on: newState :0:
2017.02.09 22:36:24 5: SOMFY_set: handled for drive/udpate: updateState :50: drivet :6.5: updatet :0:
2017.02.09 22:36:24 4: SOMFY_UpdateState: rollBuero enter with newState:0: updatestate:50: move:on:
2017.02.09 22:36:24 4: SOMFY_UpdateState: rollBuero after conversions newState:0: rounded:0: stateTrans:open:
2017.02.09 22:36:24 4: SOMFY_sendCommand: rollBuero -> cmd :on:
2017.02.09 22:36:24 5: SOMFY_sendCommand: rollBuero -> message :sA2400122000059:
2017.02.09 22:36:24 4: SOMFY_set: rollBuero -> stopping in 6.5 sec
2017.02.09 22:36:25 4: SOMFY_set: rollBuero -> entering with mode :virtual: cmd :on: arg1 :: pos :0:
2017.02.09 22:36:25 4: SOMFY_set: handled command on --> move :on: newState :2:
2017.02.09 22:36:25 5: SOMFY_set: handled for drive/udpate: updateState :200: drivet :0: updatet :14.65:
2017.02.09 22:36:25 4: SOMFY_UpdateState: rollBuero enter with newState:2: updatestate:200: move:on:
2017.02.09 22:36:25 4: SOMFY_UpdateState: rollBuero after conversions newState:2: rounded:0: stateTrans:open:
2017.02.09 22:36:25 4: SOMFY_set: rollBuero -> update state in 14.65 sec
2017.02.09 22:36:25 1: usb create starting
2017.02.09 22:36:26 3: Probing CUL device /dev/ttyAMA0
2017.02.09 22:36:26 3: Probing TCM_ESP3 device /dev/ttyAMA0
2017.02.09 22:36:26 3: Probing FRM device /dev/ttyAMA0
2017.02.09 22:36:32 1: usb create end
2017.02.09 22:36:32 3: CUL_0: Unknown code YsA2410122590000, help me!
2017.02.09 22:36:32 4: SOMFY_TimedUpdate
2017.02.09 22:36:32 5: SOMFY_TimedUpdate : pos so far : 2
2017.02.09 22:36:32 5: SOMFY_TimedUpdate : delta time : 6.75 new rounde pos (rounded): 53.9230769230769
2017.02.09 22:36:32 4: SOMFY_UpdateState: rollBuero enter with newState:53.9230769230769: updatestate:200: move:on:
2017.02.09 22:36:32 4: SOMFY_UpdateState: rollBuero after conversions newState:53.9230769230769: rounded:50: stateTrans:50:
2017.02.09 22:36:32 4: SOMFY_TimedUpdate: rollBuero -> update state in 7.9 sec
2017.02.09 22:36:32 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486676195.02196
2017.02.09 22:36:32 5: SOMFY_TimedUpdate DONE
2017.02.09 22:36:35 4: SOMFY_TimedUpdate
2017.02.09 22:36:35 5: SOMFY_TimedUpdate : pos so far : 53.9230769230769
2017.02.09 22:36:35 5: SOMFY_TimedUpdate : delta time : 2.99 new rounde pos (rounded): 76.9230769230769
2017.02.09 22:36:35 4: SOMFY_UpdateState: rollBuero enter with newState:76.9230769230769: updatestate:200: move:on:
2017.02.09 22:36:35 4: SOMFY_UpdateState: rollBuero after conversions newState:76.9230769230769: rounded:80: stateTrans:80:
2017.02.09 22:36:35 4: SOMFY_TimedUpdate: rollBuero -> update state in 4.91 sec
2017.02.09 22:36:35 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486676198.01448
2017.02.09 22:36:35 5: SOMFY_TimedUpdate DONE
2017.02.09 22:36:38 4: SOMFY_TimedUpdate
2017.02.09 22:36:38 5: SOMFY_TimedUpdate : pos so far : 76.9230769230769
2017.02.09 22:36:38 5: SOMFY_TimedUpdate : delta time : 2.99 new rounde pos (rounded): 99.9230769230769
2017.02.09 22:36:38 4: SOMFY_UpdateState: rollBuero enter with newState:99.9230769230769: updatestate:200: move:on:
2017.02.09 22:36:38 4: SOMFY_UpdateState: rollBuero after conversions newState:99.9230769230769: rounded:100: stateTrans:100:
2017.02.09 22:36:38 4: SOMFY_TimedUpdate: rollBuero -> update state in 1.92 sec
2017.02.09 22:36:38 5: SOMFY_TimedUpdate: rollBuero -> next time to stop: 1486676199.92704
2017.02.09 22:36:38 5: SOMFY_TimedUpdate DONE
2017.02.09 22:36:39 4: SOMFY_TimedUpdate
2017.02.09 22:36:39 5: SOMFY_TimedUpdate : pos so far : 99.9230769230769
2017.02.09 22:36:39 5: SOMFY_TimedUpdate : delta time : 1.91 new rounde pos (rounded): 195
2017.02.09 22:36:39 4: SOMFY_UpdateState: rollBuero enter with newState:200: updatestate:<undef>: move:stop:
2017.02.09 22:36:39 4: SOMFY_UpdateState: rollBuero after conversions newState:200: rounded:200: stateTrans:closed:
2017.02.09 22:36:39 5: SOMFY_TimedUpdate DONE
2017.02.09 22:44:29 3: CUL_HM set Therm_Buero_Climate desired-temp 30.0
2017.02.09 22:46:08 3: CUL_HM set Therm_Buero_Climate desired-temp 19.0
ich habe jetzt das ganze auf globan verbose 5 gezimmert, und knapp 20 minuten gewartet, es kam keine cul meldung, dann einmal beim somfy auf mygo /stop getriggert und bäng ist die cul meldung da.
man sieht auch das der cul sich nicht abgemeldet hat.
2017.02.09 23:07:15 4: WEB_192.168.178.86_64626 POST /fhem?cmd.rollBuero=set%20rollBuero%20%20Stop&room=Rolladen&XHR=1&fw_id=508; BUFLEN:0
2017.02.09 23:07:15 5: Cmd: >set rollBuero Stop<
2017.02.09 23:07:15 4: SOMFY_set: rollBuero -> entering with mode :send: cmd :stop: arg1 :: pos :200:
2017.02.09 23:07:15 4: SOMFY_set: handled command stop --> move :stop: newState :200:
2017.02.09 23:07:15 5: SOMFY_set: handled for drive/udpate: updateState :: drivet :0: updatet :0:
2017.02.09 23:07:15 4: SOMFY_UpdateState: rollBuero enter with newState:200: updatestate:<undef>: move:stop:
2017.02.09 23:07:15 4: SOMFY_UpdateState: rollBuero after conversions newState:200: rounded:200: stateTrans:closed:
2017.02.09 23:07:15 4: SOMFY_sendCommand: rollBuero -> cmd :stop:
2017.02.09 23:07:15 4: SOMFY set rollBuero stop: sA3110123000059
2017.02.09 23:07:15 5: SOMFY_sendCommand: rollBuero -> message :sA3110123000059:
2017.02.09 23:07:15 5: CUL_0 sending YsA3110123000059
2017.02.09 23:07:15 4: CUL_send: CUL_0Ys A3 11 0123 000059
2017.02.09 23:07:15 4: name: /fhem?cmd.rollBuero=set%20rollBuero%20%20Stop&room=Rolladen&XHR=1&fw_id=508 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2017.02.09 23:07:16 4: FHEMduino_SomfyR - Roll_Buero found SOMFY device rollBuero sent command :stop:
2017.02.09 23:07:16 4: Roll_Buero: call setFn virtual in SOMFY - YsA0B00000590000
2017.02.09 23:07:16 4: SOMFY_set: rollBuero -> entering with mode :virtual: cmd :stop: arg1 :: pos :200:
2017.02.09 23:07:16 4: SOMFY_set: handled command stop --> move :stop: newState :200:
2017.02.09 23:07:16 5: SOMFY_set: handled for drive/udpate: updateState :: drivet :0: updatet :0:
2017.02.09 23:07:16 4: SOMFY_UpdateState: rollBuero enter with newState:200: updatestate:<undef>: move:stop:
2017.02.09 23:07:16 4: SOMFY_UpdateState: rollBuero after conversions newState:200: rounded:200: stateTrans:closed:
2017.02.09 23:07:16 5: Starting notify loop for Roll_Buero, 2 event(s), first is 11
2017.02.09 23:07:16 5: ZE.Activity: not on any display, ignoring notify
2017.02.09 23:07:16 5: ZE.Batterie: not on any display, ignoring notify
2017.02.09 23:07:16 5: End notify loop for Roll_Buero
2017.02.09 23:07:16 4: FHEMduino_SomfyR reject duplicate message :Ys a3 10 0123 590000:
2017.02.09 23:07:16 4: FHEMduino_SomfyR reject duplicate message :Ys a3 10 0123 590000:
2017.02.09 23:07:16 4: FHEMduino_SomfyR reject duplicate message :Ys a3 10 0123 590000:
2017.02.09 23:07:16 4: FHEMduino_SomfyR reject duplicate message :Ys a3 10 0123 590000:
2017.02.09 23:07:16 4: FHEMduino_SomfyR reject duplicate message :Ys a3 10 0123 590000:
2017.02.09 23:07:16 5: CUL/RAW: /YsA3140123590000
2017.02.09 23:07:16 4: CUL_Parse: CUL_0 Y sA 31 4012 359000 0
2017.02.09 23:07:16 5: CUL_0: dispatch YsA3140123590000
2017.02.09 23:07:16 5: Starting notify loop for CUL_0, 1 event(s), first is UNKNOWNCODE YsA3140123590000
2017.02.09 23:07:16 5: ZE.Activity: not on any display, ignoring notify
2017.02.09 23:07:16 5: ZE.Batterie: not on any display, ignoring notify
2017.02.09 23:07:16 5: Triggering initialUsbCheck
2017.02.09 23:07:16 4: initialUsbCheck exec usb create
2017.02.09 23:07:16 5: Cmd: >usb create<
2017.02.09 23:07:16 1: usb create starting
2017.02.09 23:07:17 4: ### ttyACM0: checking if it is a CUL
2017.02.09 23:07:17 4: ttyACM0 is already used by the fhem device CUL_0
2017.02.09 23:07:17 4: ### ttyAMA0: checking if it is a CUL
2017.02.09 23:07:17 3: Probing CUL device /dev/ttyAMA0
2017.02.09 23:07:17 5: SW: 0a
2017.02.09 23:07:17 5: SW: 560a
2017.02.09 23:07:17 4: got wrong answer for a CUL
2017.02.09 23:07:17 4: ### ttyAMA0: checking if it is a TCM_ESP3
2017.02.09 23:07:17 3: Probing TCM_ESP3 device /dev/ttyAMA0
2017.02.09 23:07:17 5: SW: 5500010005700838
2017.02.09 23:07:17 4: got wrong answer for a TCM_ESP3
2017.02.09 23:07:17 4: ### ttyAMA0: checking if it is a FRM
2017.02.09 23:07:17 3: Probing FRM device /dev/ttyAMA0
2017.02.09 23:07:17 5: SW: f9
2017.02.09 23:07:22 5: SW: f079f7
2017.02.09 23:07:22 4: got wrong answer for a FRM
2017.02.09 23:07:22 4: ### ttyUSB0: checking if it is a TCM_ESP3
2017.02.09 23:07:22 4: ttyUSB0 is already used by the fhem device FHEMduino
2017.02.09 23:07:22 1: usb create end
2017.02.09 23:07:22 5: End notify loop for CUL_0
2017.02.09 23:07:22 3: CUL_0: Unknown code YsA3140123590000, help me!
2017.02.09 23:07:22 4: WEB_192.168.178.86_64626 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2017-02.log; BUFLEN:
Ist schon ein komisches Problem, sieht auch ein bisschen so aus, als ob es mehrere Probleme sind. Ich versuche mal zu beschreiben was auffällig ist:
- Bei jedem Somfy-Befehl über den CUL startet ein USB-Check -> ich muss mal schauen was das triggert, aber normal ist das nicht und das System hängt dort wohl auch für ein paar Sekunden?
- Von irgendwo wird der Somfy-Device nach absetzen eines Kommandos wieder aufgerufen:
Hier kommt der Pos 50 Befehl
22:36:24 4: SOMFY_set: rollBuero -> entering with mode :send: cmd :pos: arg1 :50: pos :0:
Dann kommt die Behandlung, Kommando wird geschickt und der Timer für 6.5 Sec wird gesetzt
2017.02.09 22:36:24 4: SOMFY_set: rollBuero -> stopping in 6.5 sec
Damit ist der pos 50-Befehl erstmal durch (Timer läuft).
ABER: Direkt danach wird ein "on" (ohne pos beschränkung) aufgerufen und zwar virtuell - sprich ohne Sendekommandos (d.h. es kommt vielleicht von einem FHEMDuino ?)
2017.02.09 22:36:25 4: SOMFY_set: rollBuero -> entering with mode :virtual: cmd :on: arg1 :: pos :0:
Das sorgt natürlich dafür dass der pos 50-Befehl überschrieben wird und der Rolladen bis in die Endposition läuft.
Ich kann nicht sagen, ob die beiden Problem zusammenhängen aber beides habe ich so noch nicht gesehen. Das USB-Problem erscheint mir erstmal schlimmer, da das ganze FHEM wohl für Sekunden steht und nicht klar ist, ob es mit dem 2. Problem zu tun hat!
Zitat von: viegener am 10 Februar 2017, 09:41:24
- Bei jedem Somfy-Befehl über den CUL startet ein USB-Check -> ich muss mal schauen was das triggert, aber normal ist das nicht und das System hängt dort wohl auch für ein paar Sekunden?
Ich habe mal gerade ein wenig geschaut: Die usb...-Meldungen kommen wohl aus dem autocreate-Modul (normalerweise werden diese über den Befehl "usb create" getriggert). Autocreate wird aber normalerweise auch aus dem Empfang von unbekannten Devices getriggert. Vielleicht hängt das zusammen, auch wenn ich es nicht verstehe...
Schaut fast so aus s als ob der cul seine eigene Sendung empfangen würde .
2017.02.09 23:07:22 3: CUL_0: Unknown code YsA3140123590000, help me![\code]
Denn 000059 ist die Adresse die ich im Somfy für den Büro shutter angelegt habe. Sitze direkt daneben deshalb teste ich meist daran. Der raspi ist im HWR, bessere funkausbreitung.
Bei den anderen reagiert es genauso, nur mit den entsprechenden Adressen.
Gesendet von meinem E6853 mit Tapatalk
und nun kommt es, der fhemduino wird wohl vom somfymodule getriggert.
ich habe des nun auf die harte variante getestet, und abgezogen, nun stoppt der wie er soll.
jedoch warum sendet der fhemduino den somfycode zusätzlich, bringt ja eigendlich keinen sinn.
@blackstone: ich habe deine verbose logs nochmal angeschaut:
Du hast 3 devices:
rollBuero - SOMFY - addresse: 000059
Roll_Buero - fhemduino-SomfyR
fb_... - fhemduino-SomfyR
Korrekt?
Zitat von: BlackStone am 10 Februar 2017, 12:11:14
und nun kommt es, der fhemduino wird wohl vom somfymodule getriggert.
ich habe des nun auf die harte variante getestet, und abgezogen, nun stoppt der wie er soll.
jedoch warum sendet der fhemduino den somfycode zusätzlich, bringt ja eigendlich keinen sinn.
Nein der fhemduino empfängt natürlich was der CUL sendet, dass ist ja ein SOMFY-Funksignal und genau darauf reagiert der fhemduino...
Der fhemduino empfängt das Signal und verarbeitet es, er sendet kein Somfy
Ich nehme an es ist so wie oben bereits vermutet es gibt ein fhemduino... device, dass hier das problem auslöst
@blackstone: Kannst Du mal ein List vom device Roll_Buero machen?
Nicht ganz, hatte zwischen 2 logpostings die Roll_Buero - fhemduino-SomfyR umgetauft in fb_Roll_Buero den rest eben nach gleichen schema.
so das es optisch klar ist was von fhem kommt und was vom wandfunkschalter kommt.
so das tatsächlich nur 2 da sind.
Internals:
ADDRESS 000059
DEF 000059
IODev FHEMduino
NAME Roll_Buero
NR 53
STATE 20
TYPE FHEMduino_SomfyR
Readings:
2017-02-10 12:02:13 command 20
2017-02-10 12:02:13 state 20
Attributes:
IODev FHEMduino
rawDevice 000059
room FHEMduino_SomfyR
komisch des sollte doch
Internals:
.eventMapCmd Auf:noArg Zu:noArg Stop:noArg Sonne:noArg
ADDRESS 000059
DEF 000059
IODev CUL_0
NAME rollBuero
NR 50
STATE open
TYPE SOMFY
move stop
Code:
1 000059
Readings:
2017-02-10 12:14:25 enc_key A6
2017-02-10 12:14:36 exact 0
2017-01-03 17:13:51 parsestate on
2017-02-10 12:14:36 position 0
2017-02-10 12:14:25 rolling_code 0136
2017-02-10 12:14:36 state open
Attributes:
IODev CUL_0
devStateIcon open:fts_shutter_10 10:fts_shutter_10 20:fts_shutter_20 30:fts_shutter_30 40:fts_shutter_40 50:fts_shutter_50 60:fts_shutter_60 70:fts_shutter_70 80:fts_shutter_80 90:fts_shutter_90 down:fts_shutter_100 closed:fts_shutter_100
drive-down-time-to-100 13
drive-down-time-to-close 15
drive-up-time-to-100 3
drive-up-time-to-open 17
eventMap off:Auf on:Zu stop:Stop go-my:Sonne
model somfyshutter
positionInverse 0
room Rolladen
verbose 5
webCmd Auf: Stop: Zu:Sonne der sein.
edit:/ ich schmeiss mal alle fhemduino geräte aus der config.
edit:// das gibt es nicht der hat statt umzubenennen die nochmals angelegt und die alten verschoben nach hidden. sind alle als somfy und fehemduino mit gleicher kennung da.
Zitat von: BlackStone am 10 Februar 2017, 12:25:52
Internals:
ADDRESS 000059
DEF 000059
IODev FHEMduino
NAME Roll_Buero
NR 53
STATE 20
TYPE FHEMduino_SomfyR
Readings:
2017-02-10 12:02:13 command 20
2017-02-10 12:02:13 state 20
Attributes:
IODev FHEMduino
rawDevice 000059
room FHEMduino_SomfyR
Da ist er doch: Dieser fhemduino-SomfyR device reagiert auf die Adresse 00059 und leitet alles was er findet an den Somfy-Device 00059 weiter und der bekommt dann sein eigenes Kommando wieder vorgesetzt - BINGO
Kurze Erklärung:
- FHEMDUINO-SomfyR devices sollten für die Handfernbedienungsadressen angelegt werden und in rawdevice stehen bei diesen dann die Adressen der SOMFY-Devices -> Grund: Wenn die FB betätigt wird, dann bekommt es der SOMFY-Device mit und verändert den Status entsprechend ohne selber Kommandos zu senden
- FHEMDUINO-SomfyR devices für die SOMFY-Devices kann man anlegen (werden zum Teil sogar automatisch angelegt) diese sollten aber keine rawDevice-Attribut tragen und können auch mit attribute ignore auf 1 versteckt werden.
ich habe die nun alle per sammelraum rausgeworfen. und nu teste ich noch mal mit fhemduino dran.
natürlich nach neustart. ;)
edit:/ also sollte ich dann den ignore setzen, wenn das rawdevice drin ist ?
so das, dass Somfy device den status zwar von der fb bekommt, das fhemduino ansonsten aber nix macht damit?
so wie es ausschaut, war der versteckte Doppler der Auslöser.
mit angeschlossenem fhemduino macht der den pos Befehl auch sauber, und reagiert nun auch sauber auf die wandfunke vom shutter.
ist mir jetzt nur ein Rätsel warum der statt umbenennen den verdoppelt hat, naja hab vorsichtshalber nochmal die rechte auf der Konsole neugesetzt.
Zitat von: BlackStone am 10 Februar 2017, 12:46:49
edit:/ also sollte ich dann den ignore setzen, wenn das rawdevice drin ist ?
so das, dass Somfy device den status zwar von der fb bekommt, das fhemduino ansonsten aber nix macht damit?
Nein: den ignore solltest Du nur setzen, wenn das ein fhemduino-device mit der Adresse des SOMFY-Devices ist - diese sollen ja ignoriert werden
Für die wirklich in Benutzung befindlichen Fernbedienungen kein ignore setzen, denn die werde ja für die Weiterleitung gebraucht
Ok, dann habe ich es jetzt richtig.
Da muss man erstmal hinterkommen mit dem Doppler.
Manchmal ist es doch besser die config per hand zu filzen. [emoji23]
Gesendet von meinem E6853 mit Tapatalk
Zitat von: BlackStone am 10 Februar 2017, 13:58:07
Ok, dann habe ich es jetzt richtig.
Da muss man erstmal hinterkommen mit dem Doppler.
Manchmal ist es doch besser die config per hand zu filzen. [emoji23]
Gesendet von meinem E6853 mit Tapatalk
Ja ist ein Fall, der nicht abgefangen ist. Wenn der FHEMDuino weiterentwickelt würde, könnte man das da noch einbauen, ich bin aber eher dabei mich auf die Kopplung mit dem Signalduino zu konzentrieren.
ne denn flash ich halt um wenn es soweit ist, hab ja gesehen das du im git einen Sduino fork drin hast.
denn ich nutze den nur für die somfys.
sehe ich das richtig das die 10_SOMFY.pm
schon auf Signalduino und fhemduino zusammen ausgelegt ist, dann kann ich ja einfach die "SIGNALduino_nano328.hex" bei mir so draufhauen.
In Beantwortung einer Anfrage hier https://forum.fhem.de/index.php/topic,24158.msg605526.html#msg605526 (https://forum.fhem.de/index.php/topic,24158.msg605526.html#msg605526) und hier https://forum.fhem.de/index.php/topic,69019.msg605001.html#msg605001 (https://forum.fhem.de/index.php/topic,69019.msg605001.html#msg605001). Damit das ganze im SOMFY-Modul thread verfolgt werden kann:
Zitat von: gessi am 15 März 2017, 14:58:07
Hallo,
ich habe einen 3-Kanal Somfy Aussenrollo welchen ich anhand der Anleitungen auch per nanoCUL (433Mhz) anlernen konnte.
Nun habe ich aber das Problem dass meine Somfy Fernbedienung (das Original) wohl ein Drehrad hat mit welchem sich der Winkel der Jalousien einstellen lässt:
https://www.somfy.de/produkte/1810765/telis-4-mod-var-rts
Wenn ich nun die On/Off Funktion drücke in FHEM wird immer die Drehrad Funktionen (hier also nur ca. 2s) an den Somfy Empfänger geschickt und nicht die Funktionen Up/Down (dass die gesamte Jalousie geschloßen oder geöffnet werden soll)!?
D.h. die Jalousie bewegt sich nur ca. 2 Sekunden...
Wie kann ich die Jalousie denn komplett schließen und öffnen lassen in FHEM?
Screenshots anbei...
P.S.: Die "go-my" Funktion kann ich nutzen und somit den Rolladen schließen wenn ich die "my" (Favoritenstellung) des Rolladens auf komplett schließen setze.
@gessi: Gute Frage ;)
Ich habe leider kein solches Aussenrollo und bin deshalb auf Input von Dir angewiesen um die Frage vielleicht beantworten zu können und/oder dann das Modul anzupassen:
Was passiert, wenn Du ON sendest und nachdem es sich 2 Sekunden bewegt hat nochmals ON auslöst?
Hast Du mal versucht die Spezialfunktionen wind_sun_9 oder wind_only_a per set an die Jalousie zu senden? - was passiert dann?
Zitat von: viegener am 15 März 2017, 15:28:40
@gessi: Gute Frage ;)
Ich habe leider kein solches Aussenrollo und bin deshalb auf Input von Dir angewiesen um die Frage vielleicht beantworten zu können und/oder dann das Modul anzupassen:
Was passiert, wenn Du ON sendest und nachdem es sich 2 Sekunden bewegt hat nochmals ON auslöst?
Hast Du mal versucht die Spezialfunktionen wind_sun_9 oder wind_only_a per set an die Jalousie zu senden? - was passiert dann?
Also das habe ich getestet, hier das Ergebnis (mittlerweile habe ich die Singalduino Firmware geflasht auf meinem nanoCUL aber leider selbiges Ergebnis https://wiki.fhem.de/wiki/Somfy_via_SIGNALduino (https://wiki.fhem.de/wiki/Somfy_via_SIGNALduino)):
- on: Rolladen bewegt sich ca. 2-3 Sekunden nach unten (falls er nicht ganz geschlossen ist natürlich)
- on (nach 5 sekunden): Rolladen bewegt sich ca. 2-3 Sekunden nach unten
- wind_sun_9: Es passiert NICHTS
- wind_only_a: Es passiert NICHTS
- stop: Der Rollanden fährt auf die "go-my" Position
Hi,
kann mir jemand mit den Readings vom parsestate helfen? Ich möchte physikalische Schalter einbinden, die beim ersten Druck z.B. nach oben fahren und beim zweiten Druck den Rolladen stoppen. Ich hatte es erst hiermit versucht
Schalter1_links:off { if (ReadingsVal("Rolladen","parsestate","") ne "up") { fhem("set Rolladen up") } else { fhem("set Rolladen stop") } }
Doch das landet immer im "else". Die Eingabe von {ReadingsVal("Rolladen","parsestate","")}
Gibt auch interessante Werte zurück. Wird in der Ansicht des Rolladen in FHEM darin noch ein up bzw. down angezeigt, so zeigt sich bei genauerer Betrachtung, dass der Wert lediglich "on" bzw. "off" liefert. Z.B. wird dies auch angezeigt, wenn man die Seite neu lädt während der Rolladen sich bewegt.
Hat einer einen Tipp, wie ich eine Abfrage bauen kann um mein Ziel zu erreichen?
Zitat von: gessi am 15 März 2017, 15:43:54
Also das habe ich getestet, hier das Ergebnis (mittlerweile habe ich die Singalduino Firmware geflasht auf meinem nanoCUL aber leider selbiges Ergebnis https://wiki.fhem.de/wiki/Somfy_via_SIGNALduino (https://wiki.fhem.de/wiki/Somfy_via_SIGNALduino)):
- on: Rolladen bewegt sich ca. 2-3 Sekunden nach unten (falls er nicht ganz geschlossen ist natürlich)
- on (nach 5 sekunden): Rolladen bewegt sich ca. 2-3 Sekunden nach unten
- wind_sun_9: Es passiert NICHTS
- wind_only_a: Es passiert NICHTS
- stop: Der Rollanden fährt auf die "go-my" Position
Oh je - das sieht noch nicht gut aus. Kannst DU noch einen Versuch machen:
Zweimal kurz hintereinander on senden, während sich das Rollo noch bewegt?
(Das Verhalten bei stop ist übrigens ganz normal weil es für my-pos keinen eigenen Befehl gibt sondern stop heisst entweder anhalten in der Bewegung oder my-pos wenn der Rolladen still steht)
Hast Du eigentlich so eine Fernbedienung, wie auf dem Bild? Wenn ja könnte man ja mal versuchen rauszufinden,w as die Fernbedienung sendet. Ich vermute, dass die Fernbedienung vielleicht alle 2-3 Sekunden weitere Fahrbefehle sendet und dadurch der Effekt erreicht wird.
Hi,
als workaround evtl. eine Abwandlung einer notify Endlosschleife:
define SomfyClose notify SomfyButton:state.defined set SomfyButton on
Über das Ende müsste man sich noch Gedanken machen (evtl. Nach gegebener Zeit attr SomfyClose disable 1)
Gruß Arnd
Raspi2 mit FHEM, CUL, MySensor, HomeBridge, Presence, Bravia, ...
Zitat von: viegener am 15 März 2017, 16:08:04
Oh je - das sieht noch nicht gut aus. Kannst DU noch einen Versuch machen:
Zweimal kurz hintereinander on senden, während sich das Rollo noch bewegt?
(Das Verhalten bei stop ist übrigens ganz normal weil es für my-pos keinen eigenen Befehl gibt sondern stop heisst entweder anhalten in der Bewegung oder my-pos wenn der Rolladen still steht)
Hast Du eigentlich so eine Fernbedienung, wie auf dem Bild? Wenn ja könnte man ja mal versuchen rauszufinden,w as die Fernbedienung sendet. Ich vermute, dass die Fernbedienung vielleicht alle 2-3 Sekunden weitere Fahrbefehle sendet und dadurch der Effekt erreicht wird.
Das hatte ich Anfangs auch vermutet aber ich denke das macht die Fernbedienung nicht... es passiert nämlich Nichts wenn man den On Button wiederholt drückt während sich der Rollo nach unten bewegt. Erst wenn dieser wieder gestoppt ist kann man per On den Rollo bewegen.
Ja ich habe diese Fernbedienung, in der Mitte befindet sich das Drehrad für die Lamellen. Ich kann mit meinem Signalduino die original FB auslesen wenn Du mir sagst wie ich das machen soll.
Zitat von: viegener am 15 März 2017, 16:08:04
Hast Du eigentlich so eine Fernbedienung, wie auf dem Bild?
die Telis 4 Mod/Var RTS sollte das erweiterte Funkprotokoll senden (Lamellen-Stellung). Falls SIGNALduino benutzt wird, könnte man auch das Senden dort korrigieren (die abschließende Pause wird weg gelassen).
Zitat von: habeIchVergessen am 16 März 2017, 10:50:32
die Telis 4 Mod/Var RTS sollte das erweiterte Funkprotokoll senden (Lamellen-Stellung). Falls SIGNALduino benutzt wird, könnte man auch das Senden dort korrigieren (die abschließende Pause wird weg gelassen).
Danke für den Hinweis, ja ich denke Du hast Recht. Ich nutze einen Singalduino (siehe Screenshot). Kannst Du mir jetzt noch erklären was ich genau machen muss?
00_SIGNALduino.pm ändern
alt
"43" => ## Somfy RTS
{
name => 'Somfy RTS',
id => '43',
clockrange => [610,670], # min , max
format => 'manchester',
preamble => 'Ys',
clientmodule => 'SOMFY', # not used now
modulematch => '^YsA[0-9A-F]{13}',
length_min => '56',
length_max => '56',
method => \&SIGNALduino_SomfyRTS, # Call to process this message
msgIntro => 'SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;',
#msgOutro => 'SR;P0=-30415;D=0;',
frequency => '10AB85550A',
},
neu
msgOutro => 'SR;P0=-2560;D=000000000000;',
reload 00_SIGNALduino/shutdown restart
wenn du verbose auf 4 gestellt hast, dann kannst du bitte mal die empfangenen Nachrichten posten. Länge interessiert mich. Sollte dann > 56 sein.
Zitat von: habeIchVergessen am 16 März 2017, 10:50:32
die Telis 4 Mod/Var RTS sollte das erweiterte Funkprotokoll senden (Lamellen-Stellung). Falls SIGNALduino benutzt wird, könnte man auch das Senden dort korrigieren (die abschließende Pause wird weg gelassen).
Hast Du einen Link zum erweiterten Protokoll ?
wenn ich mich recht erinnere, denn gibt es nur wage Beschreibungen.
32 zusätzliche Bits + das 1 Bit nach v1-Daten ist HIGH (schwirrt mir noch im Kopf).
FIG. 4 shows the organization of the data in a new generation RTS frame. It is seen that the frame of the new generation protocol contains a first part constituted by an RTS base frame of 56 bits to which a second part constituted by 24 bits of additional information is added; in particular a relay bit and 23 other bits which can be used for the transmission of data complementary to the data of the base frame. In the context of the invention, the second part of frame transmitted is preferably linked to the first part, i.e. the second data will make it possible to better define the information of the first data transmitted in the RTS base frame. For example, the additional information completes or parameterizes the RTS base frame by adding new functionalities and new parameters, whilst tightening the security of the transmission, etc. The additional information does not necessarily have an intrinsic value, i.e. it may be of no purpose is it is taken independently of the RTS base frame. In this case, if the information of the data of the first part of frame is encrypted for security reasons, it will not be necessary to encrypt the information of the second additional data of the second part of the frame, which in itself does not have a particular control function. If the second data of the second part of the frame had to be encrypted however, the same encryption key as that used for the first data of the RTS base frame could be used, or another encryption key, transmitted with the second data in the second part of the frame. (http://www.google.com/patents/US8189620)
sind nur 24 zusätzliche Bits.
Zitat von: habeIchVergessen am 16 März 2017, 12:01:36
00_SIGNALduino.pm ändern
...
wenn du verbose auf 4 gestellt hast, dann kannst du bitte mal die empfangenen Nachrichten posten. Länge interessiert mich. Sollte dann > 56 sein.
So ich habe nun Folgendes gemacht:
1. Die Datei
/opt/fhem/FHEM/00_SIGNALduino.pm angepasst (sieht nun so aus):
"43" => ## Somfy RTS
{
name => 'Somfy RTS',
id => '43',
clockrange => [610,670], # min , max
format => 'manchester',
preamble => 'Ys',
clientmodule => 'SOMFY', # not used now
modulematch => '^YsA[0-9A-F]{13}',
length_min => '56',
length_max => '56',
method => \&SIGNALduino_SomfyRTS, # Call to process this message
msgIntro => 'SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;',
msgOutro => 'SR;P0=-2560;D=000000000000;',
frequency => '10AB85550A',
},2. Das Modul neu geladen und FHEM neu gestartet:
reload 00_SIGNALduino
shutdown restart3. Verbose Level auf "4" gesetzt
attr sduino verbose 4Also wenn ich nun "ab" bzw. "on" drücke dann passiert wieder fast gar nichts.... Folgendes steht im Logfile:
2017.03.16 15:08:56 4: sduino/set: sending via SendMsg: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=A9E8E821333333;SR;P0=-2560;D=000000000000;;F=10AB85550A;
2017.03.16 15:08:56 4: sduino SendFromQueue: msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=A9E8E821333333;SR;P0=-2560;D=000000000000;;F=10AB85550A;
2017.03.16 15:08:56 4: sduino/msg READ: write new ccreg 10AB85550A
2017.03.16 15:08:56 4: sduino/msg READ: Received answer (write new ccreg 10AB85550A) for sendraw does not match ^S(R|C|M);
2017.03.16 15:08:57 4: sduino/msg READ: ccreg write back 10B0715702
2017.03.16 15:08:57 4: sduino/msg READ: Received answer (ccreg write back 10B0715702) for sendraw does not match ^S(R|C|M);
2017.03.16 15:08:57 4: sduino/msg READ: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=A9E8E821333333;SR;P0=-2560;D=000000000000;;F=10AB85550A;
2017.03.16 15:08:57 4: sduino/read sendraw answer: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=A9E8E821333333;SR;P0=-2560;D=000000000000;;F=10AB85550A;
2017.03.16 15:08:57 4: sduino/HandleWriteQueue: nothing to send, stopping timer
2017.03.16 15:08:58 4: sduino/set: sending via SendMsg: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=AAEBEB21333333;SR;P0=-2560;D=000000000000;;F=10AB85550A;
2017.03.16 15:08:58 4: sduino SendFromQueue: msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=AAEBEB21333333;SR;P0=-2560;D=000000000000;;F=10AB85550A;
2017.03.16 15:08:58 4: sduino/msg READ: write new ccreg 10AB85550A
2017.03.16 15:08:58 4: sduino/msg READ: Received answer (write new ccreg 10AB85550A) for sendraw does not match ^S(R|C|M);
2017.03.16 15:08:59 4: sduino/msg READ: ccreg write back 10B0715702
2017.03.16 15:08:59 4: sduino/msg READ: Received answer (ccreg write back 10B0715702) for sendraw does not match ^S(R|C|M);
2017.03.16 15:08:59 4: sduino/msg READ: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=AAEBEB21333333;SR;P0=-2560;D=000000000000;;F=10AB85550A;
2017.03.16 15:08:59 4: sduino/read sendraw answer: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=AAEBEB21333333;SR;P0=-2560;D=000000000000;;F=10AB85550A;
2017.03.16 15:08:59 4: sduino/HandleWriteQueue: nothing to send, stopping timer
2017.03.16 15:08:59 4: sduino/set: sending via SendMsg: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=ABEAEA21333333;SR;P0=-2560;D=000000000000;;F=10AB85550A;
2017.03.16 15:09:00 4: sduino SendFromQueue: msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=ABEAEA21333333;SR;P0=-2560;D=000000000000;;F=10AB85550A;
2017.03.16 15:09:00 4: sduino/msg READ: write new ccreg 10AB85550A
2017.03.16 15:09:00 4: sduino/msg READ: Received answer (write new ccreg 10AB85550A) for sendraw does not match ^S(R|C|M);
2017.03.16 15:09:00 4: sduino/msg READ: ccreg write back 10B0715702
2017.03.16 15:09:00 4: sduino/msg READ: Received answer (ccreg write back 10B0715702) for sendraw does not match ^S(R|C|M);
2017.03.16 15:09:00 4: sduino/msg READ: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=ABEAEA21333333;SR;P0=-2560;D=000000000000;;F=10AB85550A;
2017.03.16 15:09:00 4: sduino/read sendraw answer: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=ABEAEA21333333;SR;P0=-2560;D=000000000000;;F=10AB85550A;
2017.03.16 15:09:00 4: sduino/HandleWriteQueue: nothing to send, stopping timer
2017.03.16 15:09:02 4: sduino/set: sending via SendMsg: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=ACEDED21333333;SR;P0=-2560;D=000000000000;;F=10AB85550A;
2017.03.16 15:09:02 4: sduino SendFromQueue: msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=ACEDED21333333;SR;P0=-2560;D=000000000000;;F=10AB85550A;
2017.03.16 15:09:02 4: sduino/msg READ: write new ccreg 10AB85550A
2017.03.16 15:09:02 4: sduino/msg READ: Received answer (write new ccreg 10AB85550A) for sendraw does not match ^S(R|C|M);
2017.03.16 15:09:03 4: sduino/msg READ: ccreg write back 10B0715702
2017.03.16 15:09:03 4: sduino/msg READ: Received answer (ccreg write back 10B0715702) for sendraw does not match ^S(R|C|M);
2017.03.16 15:09:03 4: sduino/msg READ: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=ACEDED21333333;SR;P0=-2560;D=000000000000;;F=10AB85550A;
2017.03.16 15:09:03 4: sduino/read sendraw answer: SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=ACEDED21333333;SR;P0=-2560;D=000000000000;;F=10AB85550A;
2017.03.16 15:09:03 4: sduino/HandleWriteQueue: nothing to send, stopping timer
kann der sduino die Hardware-Fernbedienung empfangen? kann diese korrekt steuern?
Zitat von: habeIchVergessen am 16 März 2017, 15:27:00
kann der sduino die Hardware-Fernbedienung empfangen? kann diese korrekt steuern?
Ich habe einen nanoCUL mit cc1101 welcher keinen Empfänger hat aber wohl Befehle senden kann, dieser hat die sduino Firmware geflasht und kann logischerweise nicht empfangen.
Ich habe einen sduino mit nano328 hardware welcher auch auslesen kann und die originial Somfy Fernbedienung empfangen kann aber beim Senden wohl Probleme hat (scheint ein bekanntes Problem zu sein).
Ich habe den cc1101 als IODev zugewiesen aber leider bewegt sich eben nicht viel (2-3s on/off).
Anbei die Screenshots beider Singalduino...
Und Ja, die original Fernbedienung kann natürlich korrekt steuern.
kannst du bitte noch ein log-Auszug vom sduino328 mit verbose=4 beim Empfang posten? Bitte auch mal das Scrollrad nutzen.
Zitat von: habeIchVergessen am 16 März 2017, 16:18:41
kannst du bitte noch ein log-Auszug vom sduino328 mit verbose=4 beim Empfang posten? Bitte auch mal das Scrollrad nutzen.
Ich nutze nun den sduino (mit nano328) zum Auslesen der original Fernbedienung.
Original Fernbedienung on/ab:Zitat2017.03.16 16:25:13 4: sduino328/keepalive ok, retry = 0
2017.03.16 16:25:21 4: sduino/keepalive ok, retry = 0
2017.03.16 16:25:22 4: sduino328/msg READ: MC;LL=-1237;LH=1216;SL=-620;SH=630;D=D6F57D0BC98888E21647;C=617;L=80;
2017.03.16 16:25:22 4: sduino328: Found manchester Protocol id 43 clock 617 -> Somfy RTS
2017.03.16 16:25:22 4: sduino328: Found manchester Protocol id 52 clock 617 -> OS_PIR
2017.03.16 16:25:22 4: sduino328/msg READ: MC;LL=-1238;LH=1228;SL=-668;SH=589;D=ADEAFA17931111842C8A;C=620;L=79;
2017.03.16 16:25:22 4: sduino328: Found manchester Protocol id 43 clock 620 -> Somfy RTS
2017.03.16 16:25:22 4: sduino328: Somfy RTS preprocessing check: 7 enc: ADEAFA17931111842C8A dec: AD4710ED848200
2017.03.16 16:25:22 4: sduino328: Found manchester Protocol id 52 clock 620 -> OS_PI2017.03.16 16:26:13 4: sduino328/keepalive ok, retry = 0
2017.03.16 16:26:21 4: sduino/KeepAlive not ok, retry = 1 -> get ping
2017.03.16 16:26:21 4: sduino/msg READ: OK
2017.03.16 16:26:21 4: sduino/HandleWriteQueue: nothing to send, stopping timer
Original Fernbedienung off/auf:Zitat2017.03.16 16:27:25 4: sduino328/msg READ: MC;LL=-1260;LH=1219;SL=-691;SH=575;D=57C7CFB8FABBBBE21000;C=624;L=77;
2017.03.16 16:27:25 4: sduino328: Found manchester Protocol id 43 clock 624 -> Somfy RTS
2017.03.16 16:27:25 4: sduino328: Found manchester Protocol id 52 clock 624 -> OS_PIR
2017.03.16 16:27:25 4: sduino328/msg READ: MC;LL=-1277;LH=1190;SL=-688;SH=571;D=AF8F9F71F5777784200;C=620;L=74;
2017.03.16 16:27:25 4: sduino328: Found manchester Protocol id 43 clock 620 -> Somfy RTS
2017.03.16 16:27:25 4: sduino328: Somfy RTS preprocessing check: 0 enc: AF8F9F71F5777784200 dec: AF2010EE848200
2017.03.16 16:27:25 4: sduino328: Found manchester Protocol id 52 clock 620 -> OS_PIR
2017.03.16 16:27:25 4: sduino328/msg READ: MC;LL=-1272;LH=1190;SL=-655;SH=587;D=5F1F3EE3EAEEEF08401C;C=617;L=78;
2017.03.16 16:27:25 4: sduino328: Found manchester Protocol id 43 clock 617 -> Somfy RTS
2017.03.16 16:27:25 4: sduino328: Found manchester Protocol id 52 clock 617 -> OS_PIR
Hallo,
ich habe meine SDUINO nun endlich ans laufen gebracht. Er empfängt die Somfy Fernbedienung und ich kann die Rolladen mit Fhem fahren.
Gibt es nun eine Möglichkeit beide zu verknüpfen?
Es soll eigentlich über "rawDevice (Rolllo-Nr.)" funktionieren. Leider gibt es aber kein rawDevice in Fhem zur Auswahl?
Zitat von: gessi am 16 März 2017, 16:28:07
2017.03.16 16:25:22 4: sduino328/msg READ: MC;LL=-1237;LH=1216;SL=-620;SH=630;D=D6F57D0BC98888E21647;C=617;L=80;
2017.03.16 16:25:22 4: sduino328: Found manchester Protocol id 43 clock 617 -> Somfy RTS
2017.03.16 16:25:22 4: sduino328: Found manchester Protocol id 52 clock 617 -> OS_PIR
2017.03.16 16:25:22 4: sduino328/msg READ: MC;LL=-1238;LH=1228;SL=-668;SH=589;D=ADEAFA17931111842C8A;C=620;L=79;
2017.03.16 16:25:22 4: sduino328: Found manchester Protocol id 43 clock 620 -> Somfy RTS
2017.03.16 16:25:22 4: sduino328: Somfy RTS preprocessing check: 7 enc: ADEAFA17931111842C8A dec: AD4710ED848200
2017.03.16 16:25:22 4: sduino328: Found manchester Protocol id 52 clock 620 -> OS_PI2017.03.16 16:26:13 4: sduino328/keepalive ok, retry = 0
Da sind ja die 80 Bit. Wie es scheint hat SIGNALduino erhebliche Probleme die sauber zu empfangen.
Was empfängt sduino328, wenn sduino sendet?
Zitat von: habeIchVergessen am 16 März 2017, 17:49:46
Da sind ja die 80 Bit. Wie es scheint hat SIGNALduino erhebliche Probleme die sauber zu empfangen.
Was empfängt sduino328, sduino328 sendet?
sduino328 empfängt... der nanoCUL mit sduino Firmware sendet (hat keinen Empfänger)
Autokorrektur!
..., wenn sduino sendet?
Zitat von: habeIchVergessen am 16 März 2017, 17:54:47
Autokorrektur!
..., wenn sduino sendet?
Also der sduino328 empfängt Folgendes wenn der sduino sendet:On/Ab:Zitat2017.03.16 17:58:14 4: sduino328/HandleWriteQueue: nothing to send, stopping timer
2017.03.16 17:58:52 4: sduino328/msg READ: MC;LL=-1291;LH=1305;SL=-640;SH=626;D=5777F7909999998;C=643;L=57;
2017.03.16 17:58:52 4: sduino328: Found manchester Protocol id 43 clock 643 -> Somfy RTS
2017.03.16 17:58:52 4: sduino328/msg READ: MC;LL=-1325;LH=1278;SL=-601;SH=618;D=6266666;C=636;L=27;
2017.03.16 17:58:52 4: sduino328/msg READ: MU;P0=-1331;P1=1298;P2=635;P3=-638;D=01010232310232310232323232323102323231320132323201320231320231320231320231320231320232;CP=2;
2017.03.16 17:58:52 4: sduino328: Fingerprint for MU Protocol id 21 -> einhell garagedoor matches, trying to demodulate
2017.03.16 17:58:52 4: sduino328: Fingerprint for MU Protocol id 26 -> remote26 matches, trying to demodulate
2017.03.16 17:58:52 4: sduino328: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2017.03.16 17:58:52 4: sduino328: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2017.03.16 17:58:52 4: sduino328: Fingerprint for MU Protocol id 31 -> pollin isotronic matches, trying to demodulate
2017.03.16 17:58:52 4: sduino328: Fingerprint for MU Protocol id 36 -> socket36 matches, trying to demodulate
2017.03.16 17:58:52 4: sduino328: Fingerprint for MU Protocol id 39 -> X10 Protocol matches, trying to demodulate
2017.03.16 17:58:52 4: sduino328: Fingerprint for MU Protocol id 49 -> quigg_gt9000 matches, trying to demodulate
2017.03.16 17:58:52 4: sduino328: Fingerprint for MU Protocol id 5 -> unitec6899 matches, trying to demodulate
2017.03.16 17:58:52 4: sduino328: Fingerprint for MU Protocol id 50 -> optus_XT300 matches, trying to demodulate
2017.03.16 17:58:52 4: sduino328: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2017.03.16 17:58:52 4: sduino328: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
Off/Auf:Zitat2017.03.16 18:00:14 4: sduino328/HandleWriteQueue: nothing to send, stopping timer
2017.03.16 18:00:33 4: sduino328/msg READ: MC;LL=-1344;LH=1247;SL=-644;SH=609;D=AF8888;C=640;L=22;
2017.03.16 18:00:33 4: sduino328/msg READ: MC;LL=-1242;LH=1299;SL=-606;SH=726;D=108EAAAAAA;C=645;L=39;
wollen wir das mal sortieren:
5777F7909999998 << 1 ergibt AEEFEF213333330 encr. und AE4000CE000012 decr. Checksumme ist ok, Commando war 0x40, Adresse ist 000012, enc key AE und Rolling Code CE
AEEFEF213333330 sollte min. 4x sauber empfangen werden (insg. 6 Wiederholungen). Kann nur 1x sehen. bitte mal prüfen.
das nächste Command ist 20
raw AF2000CF000012 decr. AF2700CF120000 encr. AF888847555555
AF8888 ist ja zusehen, aber der Rest fehlt. scheint so, als ob der cul nicht gut mit der SIGNALduino-Firmware funktioniert.
Der cul hat welche Ausführung (433/868 MHz)?
Zitat von: habeIchVergessen am 16 März 2017, 18:44:14
wollen wir das mal sortieren:
5777F7909999998 << 1 ergibt AEEFEF213333330 encr. und AE4000CE000012 decr. Checksumme ist ok, Commando war 0x40, Adresse ist 000012, enc key AE und Rolling Code CE
AEEFEF213333330 sollte min. 4x sauber empfangen werden (insg. 6 Wiederholungen). Kann nur 1x sehen. bitte mal prüfen.
das nächste Command ist 20
raw AF2000CF000012 decr. AF2700CF120000 encr. AF888847555555
AF8888 ist ja zusehen, aber der Rest fehlt. scheint so, als ob der cul nicht gut mit der SIGNALduino-Firmware funktioniert.
Der cul hat welche Ausführung (433/868 MHz)?
Danke aber leider kann ich damit nicht viel anfangen... komischerweise funktioniert der "go-my" button aber auch.
Der SIGNALduino (und nun versteh ich mehr) ist ein FHEMduino der wohl nicht mit Somfy umgehen kann und deswegen auch keine Kommandos sauber empfangen noch senden kann:-Arduino Nano mit FTDI Chipsatz (hat den Vorteil bei mehreren das sie über die ID eindeutig zugeordnet werden können im Gegensatz zu einem mit CH340 Chipsatz.)
-433 Mhz Superheterodyne Receiver (Empfänger)
-433,92 Mhz Transmitter (keine 433,42 MHz Somfy Aktoren schaltbar)
-mit Sketch (sofort betriebsbereit)
-Hardware auch als SIGNALduino verwendbar
Nun hab ich halt leider noch den nanoCUL mit 433 Sender der die Kommandos senden kann, angelernt werden kann aber eben keine vernünftigen auf/ab Bewegungen ausführen kann (nur "my" geht reibungslos).
Zitat von: gessi am 16 März 2017, 16:28:07
Ich nutze nun den sduino (mit nano328) zum Auslesen der original Fernbedienung.
Original Fernbedienung on/ab:
2017.03.16 16:25:22 4: sduino328/msg READ: MC;LL=-1238;LH=1228;SL=-668;SH=589;D=ADEAFA17931111842C8A;C=620;L=79;
Original Fernbedienung off/auf:
2017.03.16 16:27:25 4: sduino328/msg READ: MC;LL=-1277;LH=1190;SL=-688;SH=571;D=AF8F9F71F5777784200;C=620;L=74;
Hattest du zwischen diesen beiden Nachrichten am Scrollrad gedreht? Waren die direkt aufeinanderfolgend?
Zitat von: habeIchVergessen am 16 März 2017, 19:07:35
Hattest du zwischen diesen beiden Nachrichten am Scrollrad gedreht? Waren die direkt aufeinanderfolgend?
Waren direkt nacheinander...Aber wie gesagt der SIGNALduino hat Probleme die Somfy Frequenzen auszulesen
wenn das 2 aufeinander folgende Tasten der Fernbedienung waren, dann müsstest du in FHEM immer zweimal das gleiche Kommando absetzen, damit es einmal akzeptiert wird. Das erste Byte ist der Encryption-Key und der wurde um 2 erhöht. Ebenso der Rolling-Code (Byte 3 und 4).
Hi,
Ihr redet wunderbar aneinander vorbei!
Egal ich habe ein Störgefühl:
Dein nanocul mit CC1101 und Signalduino Firmware kann natürlich empfangen, da der cc1101 Sender und Empfänger ist. Die Frequenz von Somfy ist aber nicht 433.920 sondern 433.420 MHz.
Mit set Name cc1101_freq 433.420 Bitte mal ändern und mit attr name verbose 4 die Originalfernbedienung belauschen und hier posten.
Gruß Arnd
Diverse RasperryPi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, WifiLight ...
Hallo zusammen,
jetzt muss ich doch mal nachfragen, da ich so langsam am verzweifeln bin.
Ich habe hier Somfy Rollos (4 Stk.) zur Beschattung, für die ich mehrere Somfy RTS Telis 4 habe.
Nun hab ich einen CUL aufgebaut aus:
- Arduino Nano
- CC1101
Und in FHEM als Signalduino eingebunden. Einen Rolladen habe ich dann testweise mal per Somfy-Modul eingebunden und per set xyz prog angelernt.
Der Rolladen bekommt die Befehle auch und fährt artig auf und ab.
Nun zum Problem:
Auf der Fernbedienung muss ich auf der jeweiligen Taste (auf/ab) länger (ca. 2sek) drauf bleiben, damit der Rollo wirklich den kompletten Weg fährt. Ansonsten fährt er nur einen kurzen Ruck.
Und genau dieser Ruck ist auch alles was ich über FHEM hinbekomme.
Liegt das an meinen Rolläden oder gilt das generell für alle Somfy RTS?
Und wie bekomm ich das gelöst?
Danke euch für jede Hilfe
Zitat von: RaspiLED am 16 März 2017, 19:16:47
Die Frequenz von Somfy ist aber nicht 433.920 sondern 433.420 MHz.
wie gepostet (https://forum.fhem.de/index.php/topic,25321.msg606062.html#msg606062) steht ja die Frequenz mit drin, sofern das Modul aktuell ist.
Oder gilt o.g. set für den Empfang?
Zitat von: fzzybllz am 16 März 2017, 19:20:19
Hallo zusammen,
jetzt muss ich doch mal nachfragen, da ich so langsam am verzweifeln bin.
Ich habe hier Somfy Rollos (4 Stk.) zur Beschattung, für die ich mehrere Somfy RTS Telis 4 habe.
Nun hab ich einen CUL aufgebaut aus:
- Arduino Nano
- CC1101
Und in FHEM als Signalduino eingebunden. Einen Rolladen habe ich dann testweise mal per Somfy-Modul eingebunden und per set xyz prog angelernt.
Der Rolladen bekommt die Befehle auch und fährt artig auf und ab.
Nun zum Problem:
Auf der Fernbedienung muss ich auf der jeweiligen Taste (auf/ab) länger (ca. 2sek) drauf bleiben, damit der Rollo wirklich den kompletten Weg fährt. Ansonsten fährt er nur einen kurzen Ruck.
Und genau dieser Ruck ist auch alles was ich über FHEM hinbekomme.
Liegt das an meinen Rolläden oder gilt das generell für alle Somfy RTS?
Und wie bekomm ich das gelöst?
Danke euch für jede Hilfe
Ich glaube ich habs hinbekommen. Bin gerade über das Attribut repetition gestolpert. Damit klappts dann schlussendlich.
Hi,
Ja genau, das set sorgt für die richtige Frequenz für den Empfang vom Somfy. Beim senden wird automatisch aber nur kurzzeitig auf die Somfy Frequenz gewechselt.
Gruß Arnd
Raspi2 mit FHEM, CUL, MySensor, HomeBridge, Presence, Bravia, ...
Zitat von: RaspiLED am 16 März 2017, 19:16:47
Hi,
Ihr redet wunderbar aneinander vorbei!
Egal ich habe ein Störgefühl:
Dein nanocul mit CC1101 und Signalduino Firmware kann natürlich empfangen, da der cc1101 Sender und Empfänger ist. Die Frequenz von Somfy ist aber nicht 433.920 sondern 433.420 MHz.
Mit set Name cc1101_freq 433.420 Bitte mal ändern und mit attr name verbose 4 die Originalfernbedienung belauschen und hier posten.
Gruß Arnd
Diverse RasperryPi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, WifiLight ...
Also ich habe das gerade gestestst aber der Sduino empfängt Nichts:
Zitat2017.03.17 10:09:01 3: sduino: Setting FREQ2..0 (0D,0E,0F) to 10 ab 85 = 433.420 MHz
2017.03.17 10:09:44 3: sduino: setting Verbose to: 4
2017.03.17 10:09:49 4: sduino/KeepAlive not ok, retry = 1 -> get ping
2017.03.17 10:09:49 4: sduino/msg READ: OK
2017.03.17 10:09:50 4: sduino/HandleWriteQueue: nothing to send, stopping timer
2017.03.17 10:10:49 4: sduino/keepalive ok, retry = 0
Ich hatte nach dem Setzen der Frequenz die On und Off Tasten gedrückt aber es wird Nichts ausgelesen.
Ich habe dieselbe Hardware-Ausstattung und ewig nichts empfangen. Dann wurde gestern (nach einem update) auf einmal ein neues Somfy-Gerät angelegt (beim Senden mit dem Handsender)
2017.03.16 18:52:36 1: SOMFY Unknown device 467FA2 (A0 002E), please define it
2017.03.16 18:52:36 2: autocreate: define SOMFY_467FA2 SOMFY 467FA2 A0 002E
2017.03.16 18:52:36 2: autocreate: define FileLog_SOMFY_467FA2 FileLog ./log/SOMFY_467FA2-%Y.log SOMFY_467FA2
Daraufhin habe ich erneut ein update vorgenommen und jetzt weist die Logdatei eine Größe von 0B auf.
defmod SOMFY_467FA2 SOMFY 467FA2 A0 002E
attr SOMFY_467FA2 IODev sduino
attr SOMFY_467FA2 alias Somfy_nicht_bedienen
attr SOMFY_467FA2 room Wohnzimmer
setstate SOMFY_467FA2 1970-01-01 01:00:00 enc_key A0
setstate SOMFY_467FA2 1970-01-01 01:00:00 rolling_code 002E
sowie
defmod FileLog_SOMFY_467FA2 FileLog ./log/SOMFY_467FA2-%Y.log SOMFY_467FA2
attr FileLog_SOMFY_467FA2 logtype text
attr FileLog_SOMFY_467FA2 room _LogFiles
setstate FileLog_SOMFY_467FA2 active
und zuletzt
defmod sduino SIGNALduino /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A104WS3F-if00-port0
attr sduino alias SIGNALduino
attr sduino devStateIcon Initialized:cul_usb@green:Open Open:cul_usb@red:Initialized
attr sduino flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
attr sduino hardware nanoCC1101
attr sduino icon cul_usb
attr sduino verbose 3
setstate sduino opened
setstate sduino 2017-03-16 23:07:14 ccconf freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)
setstate sduino 2017-03-03 22:11:32 ccreg C3E = 00 84 00 00 00 00 00 00
setstate sduino 2017-03-03 22:37:25 config MS=1;;MU=1;;MC=1
setstate sduino 2017-03-17 11:34:09 ping OK
setstate sduino 2017-03-13 21:47:29 raw ccFactoryReset done
setstate sduino 2017-03-16 23:05:47 state opened
setstate sduino 2017-03-16 23:05:47 version V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
Hallo,
ich habe heute auch versucht meinen Rolladen(Somfy RTS) mit FHEM zu verbinden.
Alles befolgt was in der Wiki steht.
Nach dem Anlernen dauerte es 5min bis ich die Fernbedienung wieder benutzen konnte und über FHEM kann ich nichts steuern.
Internals:
CFGFN
Clients :IT:CUL_TCM97001:OREGON:CUL_TX:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_WS_Maverick:SIGNALduino_un:
DEF /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
DMSG s8C009799A800
DevState initialized
DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
FD 4
MSGCNT 1169
NAME sduino
NR 90
PARTIAL
RAWMSG MS;P2=569;P3=-9050;P4=-4149;P5=-2073;D=2324252525242425252525252525252525242525242524242424252524242525242425242524;CP=2;SP=3;R=235;O;
STATE opened
TIME 1489747930
TYPE SIGNALduino
version V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 5 2017 12:39:25
Matchlist:
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}
11:SD_WS09 ^P9#[A-Fa-f0-9]+
12:SD_WS ^W\d+x{0,1}#.*
13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
14:Dooya ^P16#[A-Fa-f0-9]+
15:SOMFY ^YsA[0-9A-F]+
16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
1:IT ^i......
2:CUL_TCM97001 ^s[A-Fa-f0-9]+
4:OREGON ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
5:CUL_TX ^TX..........
7:Hideki ^P12#75[A-F0-9]+
X:SIGNALduino_un ^[uP]\d+#.*
QUEUE:
Readings:
2017-03-16 21:29:33 ping OK
2017-03-17 11:52:10 state opened
2017-03-16 17:52:08 version V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 5 2017 12:39:25
Getcmd:
Keepalive:
ok 1
retry 0
mcIdList:
10
11
12
18
43
47
msIdList:
0
1
13
14
15
17
2
22
23
25
3
32
33
35
38
4
41
45
6
7
muIdList:
16
20
21
24
26
27
28
29
30
31
34
36
37
39
40
42
44
46
48
49
5
50
51
8
9
Attributes:
flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
hardware nanoCC1101
Internals:
ADDRESS 12345F
CFGFN
DEF 12345F
IODev sduino
NAME EG_ku_RO
NR 1272
STATE open
TYPE SOMFY
move off
Code:
1 12345F
Readings:
2017-03-17 11:35:43 enc_key AF
2017-03-17 11:35:43 exact 0
2017-03-17 11:35:43 position 0
2017-03-17 11:35:43 rolling_code 001F
2017-03-17 11:35:43 state open
Attributes:
IODev sduino
devStateIcon open:fts_shutter_10 10:fts_shutter_10 20:fts_shutter_20 30:fts_shutter_30 40:fts_shutter_40 50:fts_shutter_50 60:fts_shutter_60 70:fts_shutter_70 80:fts_shutter_80 90:fts_shutter_90 down:fts_shutter_100 closed:fts_shutter_100
eventMap on:down stop:stop off:up
group Rolladen
room Küche,Alexa
verbose 5
webCmd down:stop:up
Vielleicht hat ja einer eine Idee , ich woll es nicht so oft probieren.
Gruß
Hi Timo,
Mir fehlt ein
attr sduino hardware nanoCC1101
Danach will ich ein
get sduino ccconf
sehen ;-)
Welche Frequenz ist tatsächlich eingestellt?
Zum Anlernen gibt es wohl zwei Ansätze: In einigen Anleitungen steht oben/unten Taste auf der funktionierenden Fernbedienung für 3 Sekunden gleichzeitig drücken in anderen wird der Anlernbutton auf der Rückseite der Fernbedienung für 3 Sekunden mit einer Büroklammer gedrückt. Jedenfalls wird der Modus von der Rollade durch kurzes Zucken akzeptiert. In dem neuen fhem Device (vorher ja per Hand anlegen!) Muss man dann Set Device prog ausführen.
Was hast Du probiert? Wir genau hat sich der Rolladen verhalten?
Gruß Arnd
Diverse RasperryPi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, WifiLight ...
Zitat von: andies am 17 März 2017, 11:37:00
Ich habe dieselbe Hardware-Ausstattung und ewig nichts empfangen. Dann wurde gestern (nach einem update) auf einmal ein neues Somfy-Gerät angelegt (beim Senden mit dem Handsender)
2017.03.16 18:52:36 1: SOMFY Unknown device 467FA2 (A0 002E), please define it
2017.03.16 18:52:36 2: autocreate: define SOMFY_467FA2 SOMFY 467FA2 A0 002E
2017.03.16 18:52:36 2: autocreate: define FileLog_SOMFY_467FA2 FileLog ./log/SOMFY_467FA2-%Y.log SOMFY_467FA2
Daraufhin habe ich erneut ein update vorgenommen und jetzt weist die Logdatei eine Größe von 0B auf.
defmod SOMFY_467FA2 SOMFY 467FA2 A0 002E
attr SOMFY_467FA2 IODev sduino
attr SOMFY_467FA2 alias Somfy_nicht_bedienen
attr SOMFY_467FA2 room Wohnzimmer
setstate SOMFY_467FA2 1970-01-01 01:00:00 enc_key A0
setstate SOMFY_467FA2 1970-01-01 01:00:00 rolling_code 002E
sowie
defmod FileLog_SOMFY_467FA2 FileLog ./log/SOMFY_467FA2-%Y.log SOMFY_467FA2
attr FileLog_SOMFY_467FA2 logtype text
attr FileLog_SOMFY_467FA2 room _LogFiles
setstate FileLog_SOMFY_467FA2 active
und zuletzt
defmod sduino SIGNALduino /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A104WS3F-if00-port0
attr sduino alias SIGNALduino
attr sduino devStateIcon Initialized:cul_usb@green:Open Open:cul_usb@red:Initialized
attr sduino flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
attr sduino hardware nanoCC1101
attr sduino icon cul_usb
attr sduino verbose 3
setstate sduino opened
setstate sduino 2017-03-16 23:07:14 ccconf freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)
setstate sduino 2017-03-03 22:11:32 ccreg C3E = 00 84 00 00 00 00 00 00
setstate sduino 2017-03-03 22:37:25 config MS=1;;MU=1;;MC=1
setstate sduino 2017-03-17 11:34:09 ping OK
setstate sduino 2017-03-13 21:47:29 raw ccFactoryReset done
setstate sduino 2017-03-16 23:05:47 state opened
setstate sduino 2017-03-16 23:05:47 version V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
Hey, ich habe gerade eben nochmal ein Update gemacht und nun kann ich auch die Frequenz nicht mehr einstellen wie wie vorher empfohlen:
Zitat von: RaspiLED am 16 März 2017, 19:16:47
Hi,
Ihr redet wunderbar aneinander vorbei!
Egal ich habe ein Störgefühl:
Dein nanocul mit CC1101 und Signalduino Firmware kann natürlich empfangen, da der cc1101 Sender und Empfänger ist. Die Frequenz von Somfy ist aber nicht 433.920 sondern 433.420 MHz.
Mit set Name cc1101_freq 433.420 Bitte mal ändern und mit attr name verbose 4 die Originalfernbedienung belauschen und hier posten.
Gruß Arnd
Diverse RasperryPi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, WifiLight ...
Kannst Du Mal bitte meine sduino (cc1101) device settings mit Deinen vergleichen und mir die Unterschiede nennen???
Anbei ein Screenshot meiner Konfiguration.
Da sind meine Daten. Finde sieben Unterschiede ;-)
Zuerst: DMSG ist verschieden, ich habe ein RawMSG sowie RSSI, einige Readings sind anders. Sonst alles gleich.
Zitat von: andies am 17 März 2017, 13:11:48
Da sind meine Daten. Finde sieben Unterschiede ;-)
Zuerst: DMSG ist verschieden, ich habe ein RawMSG sowie RSSI, einige Readings sind anders. Sonst alles gleich.
Hmm... die einzelnen Werte sagen mir leider Nichts :-( Dazu fehlt mir das Wissen...
Hast Du noch die genaue Prozedur wie Du das Device in FHEM registriert hattest und konfiguriert hattest? Hab ich evtl. da etwas vergessen oder falsch gemacht?
Ich habe mittlerweile auch noch einen Factory Reset mit "get raw e" gemacht aber er will und will nicht lesen. Das aber nicht nur von der SOMFY FB sondern auch von einer anderen 433Mhz FB welche ich benutze um ein Licht einzuschalten. Scheint also eher die sduino hardware zu sein.
Zitat von: RaspiLED am 17 März 2017, 12:41:07
Hi Timo,
Mir fehlt ein
attr sduino hardware nanoCC1101
Danach will ich ein
get sduino ccconf
sehen ;-)
Welche Frequenz ist tatsächlich eingestellt?
Zum Anlernen gibt es wohl zwei Ansätze: In einigen Anleitungen steht oben/unten Taste auf der funktionierenden Fernbedienung für 3 Sekunden gleichzeitig drücken in anderen wird der Anlernbutton auf der Rückseite der Fernbedienung für 3 Sekunden mit einer Büroklammer gedrückt. Jedenfalls wird der Modus von der Rollade durch kurzes Zucken akzeptiert. In dem neuen fhem Device (vorher ja per Hand anlegen!) Muss man dann Set Device prog ausführen.
Was hast Du probiert? Wir genau hat sich der Rolladen verhalten?
Gruß Arnd
Diverse RasperryPi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, WifiLight ...
@Danke Andre für deine Hilfe
attr sduino hardware nanoCC1101 das ist dabei.-)
Ich habe die Anlerntaste laut Bedienungsanleitung(somfy rts chronis smart) für 0,5sek gedrückt , dann machte der Rolladen einen kurzen Ruck und das war es auch schon.
get sduino ccconf ? Den Befehl kennt er nicht.
Wie finde ich heraus auf welche Frequenz er eingestellt ist?
Danke und Gruß
Zitat von: gessi am 17 März 2017, 13:24:27
Hast Du noch die genaue Prozedur wie Du das Device in FHEM registriert hattest und konfiguriert hattest? Hab ich evtl. da etwas vergessen oder falsch gemacht?
Zuerst einmal sagt mein Logfile
2017.03.17 13:20:16 1: PERL WARNING: Argument " " isn't numeric in numeric gt (>) at ./FHEM/10_SOMFY.pm line 543.
2017.03.17 13:20:34 1: PERL WARNING: Argument " " isn't numeric in addition (+) at ./FHEM/10_SOMFY.pm line 1199.
und da muss wohl ein Fachmann ran. Sonst: Die Somfy-Fernbedienung (ich habe nur drahtlose Motoren) umgedreht, in das kleine Loch eine Stecknadel gesteckt und eine Sekunde gewartet. Dann signalisiert das Rollo "habe verstanden" (=kurz auf-ab) und dann warte ich noch etwa eine Minute, danach kann ich schalten. Den Signalduino habe ich zusammengelötet und hineingesteckt, das war's.
Zitat von: T1mo am 17 März 2017, 13:29:03
@Danke Andre für deine Hilfe
attr sduino hardware nanoCC1101 das ist dabei.-)
Ich habe die Anlerntaste laut Bedienungsanleitung(somfy rts chronis smart) für 0,5sek gedrückt , dann machte der Rolladen einen kurzen Ruck und das war es auch schon.
get sduino ccconf ? Den Befehl kennt er nicht.
Wie finde ich heraus auf welche Frequenz er eingestellt ist?
Danke und Gruß
Seit dem Update heute kann ich weder die Frequenz einstellen noch kann ich die Auslesen.
Zitat von: T1mo am 17 März 2017, 13:29:03
Wie finde ich heraus auf welche Frequenz er eingestellt ist?
Eigentlich so
Readings
ccconf freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)Oder get sduino ccconf. Geht bei mir aber komischerweise nicht.
Zitat von: andies am 17 März 2017, 13:32:17
Eigentlich so
Readings
ccconf freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)
Oder get sduino ccconf. Geht bei mir aber komischerweise nicht.
Unknown argument ccconf, choose one of ITParms:noArg cmds:noArg config:noArg freeram:noArg ping:noArg protocolIDs:noArg raw uptime:noArg version:noArg
Update gemacht? Ist nicht unser Fehler. Wir müssen warten, bis sidey von der Arbeit kommt ;-)
Zitat von: andies am 17 März 2017, 13:37:27
Update gemacht? Ist nicht unser Fehler. Wir müssen warten, bis sidey von der Arbeit kommt ;-)
Ja, das sduino device hat die Parameter nicht mehr also kann man die Frequenz weder setzen noch Auslesen...
Hi, mit update habt ihr das normale Release eingespielt, welches kein CC1101 unterstützt.
FHEM aktualisieren: update
SIGNALduino Modul und Firmware aktualisieren: update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt
Gruß Arnd
Diverse RasperryPi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, WifiLight ...
Sorry, hatte ich vergessen zu schreiben: ich mache dieses Update, von der du schreibst - nicht die einfache Variante!
Gesendet von iPhone mit Tapatalk Pro
Und danach shutdown Reboot bzw. Reload des Moduls gemacht?
Diverse RasperryPi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, WifiLight ...
Äh, nee :(
Jetzt komplett FHEM neu gestartet - keine Änderung. Puuh, nochmal dem Tadel von der Schippe gesprungen.
Hmm, habe jetzt auch nochmal ein Update gemacht!
Der Befehl version zeigt
00_SIGNALduino.pm 10484 2017-02-26 11:00:00Z v3.3.1-dev
Ist das bei Dir auch so?
Wie sieht das list deines Signalduinos aus?
Und die get und set Befehle?
Wir suchen folgende: ccconf & cc1101_...
Auszug aus Commandref:
GET
...
ccconf
Only with cc1101 receiver. Read some CUL radio-chip (cc1101) registers (frequency, bandwidth, etc.), and display them in human readable form.
ccreg
read cc1101 registers (99 reads all cc1101 registers)
...
SET
...
freq / bWidth / rAmpl / sens
Only with CC1101 receiver.
Set the CUL frequency / bandwidth / receiver-amplitude / sensitivity
Use it with care, it may destroy your hardware and it even may be illegal to do so. Note: The parameters used for RFR transmission are not affected.
freq sets both the reception and transmission frequency. Note: Although the CC1101 can be set to frequencies between 315 and 915 MHz, the antenna interface and the antenna of the CUL is tuned for exactly one frequency. Default is 868.3 MHz (or 433 MHz)
bWidth can be set to values between 58 kHz and 812 kHz. Large values are susceptible to interference, but make possible to receive inaccurately calibrated transmitters. It affects tranmission too. Default is 325 kHz.
rAmpl is receiver amplification, with values between 24 and 42 dB. Bigger values allow reception of weak signals. Default is 42.
sens is the decision boundary between the on and off values, and it is 4, 8, 12 or 16 dB. Smaller values allow reception of less clear signals. Default is 4 dB.
Gruß Arnd
Raspi2 mit FHEM, CUL, MySensor, HomeBridge, Presence, Bravia, ...
Zitat von: RaspiLED am 18 März 2017, 02:43:26
Der Befehl version zeigt
00_SIGNALduino.pm 10484 2017-02-26 11:00:00Z v3.3.1-dev
Ist das bei Dir auch so?
Wie sieht das list deines Signalduinos aus?
Und die get und set Befehle?
Wir suchen folgende: ccconf & cc1101_...
Auszug aus Commandref:
Ja, das sieht genauso aus (nach dem Update). Weiter
ccconf: freq:433.920MHz bWidth:650KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)Die Readings hänge ich an.
Zitat von: gessi am 16 März 2017, 16:28:07
Ich nutze nun den sduino (mit nano328) zum Auslesen der original Fernbedienung.
habe mir die Nachrichten nochmals angesehen. Da werden Nachrichten für zwei Geräte gesendet. Kannst/möchtest du mehr Log-Daten für
nur ein Gerät liefern?
grep -E "sduino328/msg READ: MC;" -A 2 <Name -Log-Datei>
Speziell das Scrollrad interessiert mich.
Original Fernbedienung on/ab:D6F57D0BC98888E21647 << 1
ADEAFA15931111 C42C8E encr
AD4010EF
008286.D5E8A2 decr
ADEAFA17931111 842C8A encr
AD4010ED
008284.95A8A6 decr
Original Fernbedienung off/auf:57C7CFB8FABBBBE21000 << 1
AF8F9F71F57777 C42000 encr
AF2010EE
008284.B3E420 decr
Es gibt hier anscheinend ein neues Problem:
2017.03.18 14:30:16 1: PERL WARNING: Use of uninitialized value $ioType in string ne at ./FHEM/10_SOMFY.pm line 394.
2017.03.18 14:30:16 1: PERL WARNING: Use of uninitialized value $ioType in string eq at ./FHEM/10_SOMFY.pm line 462.
2017.03.18 14:30:16 1: PERL WARNING: Use of uninitialized value $ioType in string ne at ./FHEM/10_SOMFY.pm line 489.
dein SOMFY-Device scheint kein IODev zu haben. Deshalb gibt es in der Funktion SOMFY_SendCommand an besagten Stellen die Fehler.
Danke - das Problem hat sich irgendwie "von selbst" gelöst. Ich hatte den Befehl in einer iPhone-App ausgelöst und da fehlte in der Tat das IODev. Im Browser dagegen ist es vorhanden und nun läuft alles. Ich verstehe das aber nicht wirklich.
Hallo Viegener,
ich habe seit gestern meine orignial Somfy Fernbedienungen und Wandsender nach einer Umstellung der CUL-HW auf Signalduino-SW nun stabil in FHEM integriert (mit dem ursprünglichen Versuch die "original" Signal-/FHEMduino HW zu verwenden hatte ich nur einen Empfangsradius von 2m).
Nun stehe ich vor der Herausforderung des Pairings mit den Aktoren um die Positionszustände dauerhaft korrekt zu ermitteln.
Ich habe die Diskussion zur Überarbeitung/Neuaufsetzen des Moduls im Februar verfolgt und da ich seit dem 06.02.2017 ?? nichts mehr dazu gelesen habe, wollte ich mal höflichst nachhorchen, ob das Vorhaben noch realisiert wird, bzw. in Umsetzung ist, oder zurückgestellt/verworfen wurde.
Mit den Ansätzen die du bei der Planung aufgeführt hast, würden sich einige manuelle Konstrukte mit notifys etc. erübrigen.
Selbstverständlich stehe ich sehr gerne für ausgiebige Tests zur Verfügung.
Vielen Dank für deine Mühen und viele Grüße
Thorsten
@Grafkox: Nein das Vorhaben steht noch an, es erfordert aber deutlich mehr Zeit, da ich erstmal in Somfy etwas aufräumen musste. Ich kann keinen Termin absehen, und vermutlich muss ich das auch weiter in mehreren Schritten durchführen. Das Modul ist durch einige verschiedene Entwickler gegangen und trägt auch einiges an Altlasten mit sich herum
Danke Viegener für die schnelle Antwort.
Eine Funktion wie rawDevice wie bei fhemduino_somfyr ist wahrscheinlich zu umfangreich, um sie ggf. kurzfristig zu implementieren, oder? :-X
Zitat von: RaspiLED am 17 März 2017, 13:43:47
Hi, mit update habt ihr das normale Release eingespielt, welches kein CC1101 unterstützt.
FHEM aktualisieren: update
SIGNALduino Modul und Firmware aktualisieren: update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt
Gruß Arnd
Diverse RasperryPi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, WifiLight ...
Hallo, bei jedem Update scheint das bei mir wieder zurückgesetzt zu werden...Leider...
Wie kann ich die Update settings so machen dass jedesmal automatisch der cc1101 Support beibehalten bleibt?
Moin,
Steht schon weiter oben im Thread. Aber hier nochmal deutlicher:
"update add
Fügt ein zusätzliches Repository zur vereinfachten Nutzung über die Standardaufrufe hinzu. Ein Aufruf von update <Dateiname>|all|check|force berücksichtigt dann automatisch neben dem FHEM-eigenen Repository auch das hinzugefügte "Thirdparty-Repository"."
aus https://wiki.fhem.de/wiki/Update
Konkret:
update add https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt
Bei einem update all wird dann in Zukunft erst das normale geladen und im Anschluss sofort die Dev Version drüber geladen ;-)
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Hallo zusammen,
bin absoluter FHEM Neuling und habe mich schon an die Einbindung meiner Somfy RTS Jalousien gewagt.
Mit "on" und "off" lassen sich alle 3 Jalousien getrennt wunderbar bewegen - aber leider nur ein paar Millimeter.
Ich schaffe es leider nicht, die Jalousien mit einem Klick auf "on" ganz herunter oder einem Klick auf "off" ganz hoch fahren zu lassen.
Ich setze einen Raspberry PI3 mit einem CUL 868 ein. Und eine Somfy Telis 4 RTS Fernbedienung. Ich hätte in FHEM gerne je einen Button für "offen", "geschlossen" und "Lieblingsposition".
Meine Jalousien lassen sich auf "blickdicht" stellen, dann stehen die Lamellen senkrecht. Und auf "durchsichtig", dann stehen die Lamellen waagrecht. Lässt sich das auch umsetzen?
Vielen Dank im Voraus für Eure Unterstützung.
Grüße Mave
Ich habe das gleiche Problem...leider habe ich es nicht hinbekommen...
Hilft das?:
https://forum.fhem.de/index.php?topic=50723.0 (https://forum.fhem.de/index.php?topic=50723.0)
Zitat von: pataya am 01 Mai 2017, 13:38:30
Hilft das?:
https://forum.fhem.de/index.php?topic=50723.0 (https://forum.fhem.de/index.php?topic=50723.0)
Leider nicht... :(
Meine Fernbedienung Telis 4 RTS funktioniert folgendermaßen:
Wenn ich die Taste "hoch" oder "runter" kurz drücke, dann bewegt sich die Jalousie auch nur ganz kurz hoch oder runter.
Erst wenn ich länger auf eine Taste drücke (ca. 2 Sekunden), läuft die Jalousie selbständig hoch oder runter, auch wenn ich dann die Taste loslasse.
Das heißt, ich muss FHEM dazu bringen, dass die Taste "hoch" oder "runter" für ca. 2 Sekunden "gedrückt"bzw. gesendet wird.
Ich hoffe, ich konnte mein Problem verständlich machen.
Vielleicht hilft das Attribut "repetition", damit werden die Sendebefehle häufiger wiederholt.
Hi,
Oder die FB sendet nach 2s einen anderen Code?
Hast Du mal ein mitprotokoliertes Log für uns bei Verbose 4 oder 5?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Meinst Du so etwas hier?
Sorry, aber ich bin absoluter Newbie. :-[
2017-05-01 21:29:48 SOMFY Jalousie_rechts oben
2017-05-01 21:29:48 SOMFY Jalousie_rechts position: 0
2017-05-01 21:29:48 SOMFY Jalousie_rechts exact: 4.76190476190476
2017-05-01 21:29:51 SOMFY Jalousie_rechts 10
2017-05-01 21:29:51 SOMFY Jalousie_rechts position: 10
2017-05-01 21:29:51 SOMFY Jalousie_rechts exact: 9.50793650793651
2017-05-01 21:29:54 SOMFY Jalousie_rechts 10
2017-05-01 21:29:54 SOMFY Jalousie_rechts position: 10
2017-05-01 21:29:54 SOMFY Jalousie_rechts exact: 14.2539682539683
2017-05-01 21:29:57 SOMFY Jalousie_rechts 20
2017-05-01 21:29:57 SOMFY Jalousie_rechts position: 20
2017-05-01 21:29:57 SOMFY Jalousie_rechts exact: 19.015873015873
2017-05-01 21:30:00 SOMFY Jalousie_rechts 20
2017-05-01 21:30:00 SOMFY Jalousie_rechts position: 20
2017-05-01 21:30:00 SOMFY Jalousie_rechts exact: 23.7619047619048
2017-05-01 21:30:03 SOMFY Jalousie_rechts 30
2017-05-01 21:30:03 SOMFY Jalousie_rechts position: 30
2017-05-01 21:30:03 SOMFY Jalousie_rechts exact: 28.5079365079365
2017-05-01 21:30:06 SOMFY Jalousie_rechts 30
2017-05-01 21:30:06 SOMFY Jalousie_rechts position: 30
2017-05-01 21:30:06 SOMFY Jalousie_rechts exact: 33.2539682539683
2017-05-01 21:30:09 SOMFY Jalousie_rechts 40
2017-05-01 21:30:09 SOMFY Jalousie_rechts position: 40
2017-05-01 21:30:09 SOMFY Jalousie_rechts exact: 38
Oder das hier?
2017.05.01 21:29:45 4: SOMFY_set: Jalousie_rechts -> entering with mode :send: cmd :on: arg1 :: pos :0:
2017.05.01 21:29:45 4: SOMFY_set: handled command on --> move :on: newState :0:
2017.05.01 21:29:45 5: SOMFY_set: handled for drive/udpate: updateState :100: drivet :0: updatet :63:
2017.05.01 21:29:45 4: SOMFY_UpdateState: Jalousie_rechts enter with newState:0: updatestate:100: move:on:
2017.05.01 21:29:45 4: SOMFY_UpdateState: Jalousie_rechts after conversions newState:0: rounded:0: stateTrans:open:
2017.05.01 21:29:45 4: SOMFY_sendCommand: Jalousie_rechts -> cmd :on:
2017.05.01 21:29:45 5: SOMFY_sendCommand: Jalousie_rechts -> message :sA1400141000003:
2017.05.01 21:29:45 4: SOMFY_set: Jalousie_rechts -> update state in 63 sec
2017.05.01 21:29:45 4: SOMFY Jalousie_rechts on
2017.05.01 21:29:48 4: SOMFY_TimedUpdate
2017.05.01 21:29:48 5: SOMFY_TimedUpdate : pos so far : 0
2017.05.01 21:29:48 5: SOMFY_TimedUpdate : delta time : 3.00 new rounde pos (rounded): 4.76190476190476
2017.05.01 21:29:48 4: SOMFY_UpdateState: Jalousie_rechts enter with newState:4.76190476190476: updatestate:100: move:on:
2017.05.01 21:29:48 4: SOMFY_UpdateState: Jalousie_rechts after conversions newState:4.76190476190476: rounded:0: stateTrans:open:
2017.05.01 21:29:48 4: SOMFY_TimedUpdate: Jalousie_rechts -> update state in 60 sec
2017.05.01 21:29:48 5: SOMFY_TimedUpdate: Jalousie_rechts -> next time to stop: 1493666991.52837
2017.05.01 21:29:48 5: SOMFY_TimedUpdate DONE
2017.05.01 21:29:51 4: SOMFY_TimedUpdate
2017.05.01 21:29:51 5: SOMFY_TimedUpdate : pos so far : 4.76190476190476
2017.05.01 21:29:51 5: SOMFY_TimedUpdate : delta time : 2.99 new rounde pos (rounded): 9.50793650793651
2017.05.01 21:29:51 4: SOMFY_UpdateState: Jalousie_rechts enter with newState:9.50793650793651: updatestate:100: move:on:
2017.05.01 21:29:51 4: SOMFY_UpdateState: Jalousie_rechts after conversions newState:9.50793650793651: rounded:10: stateTrans:10:
2017.05.01 21:29:51 4: SOMFY_TimedUpdate: Jalousie_rechts -> update state in 57.01 sec
2017.05.01 21:29:51 5: SOMFY_TimedUpdate: Jalousie_rechts -> next time to stop: 1493666994.52068
2017.05.01 21:29:51 5: SOMFY_TimedUpdate DONE
2017.05.01 21:29:54 4: SOMFY_TimedUpdate
2017.05.01 21:29:54 5: SOMFY_TimedUpdate : pos so far : 9.50793650793651
2017.05.01 21:29:54 5: SOMFY_TimedUpdate : delta time : 2.99 new rounde pos (rounded): 14.2539682539683
2017.05.01 21:29:54 4: SOMFY_UpdateState: Jalousie_rechts enter with newState:14.2539682539683: updatestate:100: move:on:
2017.05.01 21:29:54 4: SOMFY_UpdateState: Jalousie_rechts after conversions newState:14.2539682539683: rounded:10: stateTrans:10:
2017.05.01 21:29:54 4: SOMFY_TimedUpdate: Jalousie_rechts -> update state in 54.02 sec
2017.05.01 21:29:54 5: SOMFY_TimedUpdate: Jalousie_rechts -> next time to stop: 1493666997.51507
2017.05.01 21:29:54 5: SOMFY_TimedUpdate DONE
2017.05.01 21:29:57 4: SOMFY_TimedUpdate
2017.05.01 21:29:57 5: SOMFY_TimedUpdate : pos so far : 14.2539682539683
2017.05.01 21:29:57 5: SOMFY_TimedUpdate : delta time : 3.00 new rounde pos (rounded): 19.015873015873
2017.05.01 21:29:57 4: SOMFY_UpdateState: Jalousie_rechts enter with newState:19.015873015873: updatestate:100: move:on:
2017.05.01 21:29:57 4: SOMFY_UpdateState: Jalousie_rechts after conversions newState:19.015873015873: rounded:20: stateTrans:20:
2017.05.01 21:29:57 4: SOMFY_TimedUpdate: Jalousie_rechts -> update state in 51.02 sec
2017.05.01 21:29:57 5: SOMFY_TimedUpdate: Jalousie_rechts -> next time to stop: 1493667000.51533
2017.05.01 21:29:57 5: SOMFY_TimedUpdate DONE
2017.05.01 21:30:00 4: SOMFY_TimedUpdate
2017.05.01 21:30:00 5: SOMFY_TimedUpdate : pos so far : 19.015873015873
2017.05.01 21:30:00 5: SOMFY_TimedUpdate : delta time : 2.99 new rounde pos (rounded): 23.7619047619048
2017.05.01 21:30:00 4: SOMFY_UpdateState: Jalousie_rechts enter with newState:23.7619047619048: updatestate:100: move:on:
2017.05.01 21:30:00 4: SOMFY_UpdateState: Jalousie_rechts after conversions newState:23.7619047619048: rounded:20: stateTrans:20:
Hi,
Ich meinte setze mal das Empfangsdevice (CUL oder Signalduino?) Mittels Attribut auf Verbose 5 und öffne den Event Monitor mit Haken an fhem Log. Dann nimm mal die Fernbedienung auf bei kurzem und langen drücken.
Meine Somfy senden auf 433.420 MHz, daher evtl. vorher mal
set <device> freq 433.420
Und hinterher wieder auf 433.920 setzen.
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Danke für Deine Unterstützung.
Ich verwende einen CUL 868 von Busware mit culfw 1.66 und wenn ich das richtig verstanden habe, kann der nur senden und nicht empfangen... :(
Hi,
Du könntest zum testen die Signalduino Software draufflashen, dann kannst Du beides ;-)
Aber vorher fragen wir hier noch mal die Profis! Kann es überhaupt sein, dass es unterschiedliche Codes sind?
Gruß Arnd
Gesendet von meinem SM-G800F mit Tapatalk
Meine Telis 4 sendet immer den gleichen code.
Und egal, ob ich lang oder kurz auf Up/Down drücke, der Rollladen geht immer ganz auf oder ganz zu, bei einem Motor Oximo RTS oder Orea RTS.
Es könnte aber auch Motoren geben, die ein anderes Verhalten zeigen, das müsste aus der Bedienungsanleitung des Motors ersichtlich sein.
Hi,
Ich habe hier eine FB von Heim&Haus mit Somfy Protokoll, die sendet auch immer gleiche Codes (mit Rollingcode). Daher hilft auch die Wiederholungen am Somfy Device einzustellen.
Wie hast Du denn Dein Device in FHEM angelegt (list <Device>) und hinterher angelernt?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Ich habe es laut Wiki angelegt und danach die 3 Jalousien einzeln angelernt. Hat wunderbar funktioniert.
Ich habe auch mit <repetition> schon experimentiert und Werte von 1 bis 50 ausprobiert. Die Jalousie läuft damit aber nur geringfügig unterschiedlich lange (1 bis 3 Sekunden) runter oder hoch - aber nie vollständig.
Wie bereits gesagt, muss ich an meiner Fernbedienung ca. 2 Sekunden am Stück den hoch oder runter Knopf gedrückt halten, damit die Jalousie selbständig ganz runter oder ganz hoch fährt.
Kann ich FHEM dazu veranlassen, das hoch oder runter Signal 2 Sekunden lang zu senden?
Vielen Dank.
Grüße Mave
Bei mir funktioniert jetzt seit heute (nachdem ich wieder Mal in diesen Thread geschaut habe) das auf/ab zum allerersten Mal!!!!
Mit folgendem Attribut:
Zitatattr Rolladen_Balkon repetition 20
Niedrigere Werte als
20 haben nicht funktioniert. Ich habe dieses Attribut aus dem verlinkten Thread https://forum.fhem.de/index.php?topic=50723.0 (https://forum.fhem.de/index.php?topic=50723.0)
Zitat von: RaspiLED am 02 Mai 2017, 10:22:14
Wie hast Du denn Dein Device in FHEM angelegt (list <Device>) und hinterher angelernt?
Internals:
ADDRESS 000003
DEF 000003
IODev CUL_0
NAME Jalousie_rechts
NR 27
STATE oben
TYPE SOMFY
move off
Code:
1 000003
Readings:
2017-05-02 19:54:59 enc_key A8
2017-05-02 19:54:59 exact 0
2017-05-01 21:30:23 parsestate off
2017-05-02 19:54:59 position 0
2017-05-02 19:54:59 rolling_code 0168
2017-05-02 19:54:59 state open
Attributes:
IODev CUL_0
drive-down-time-to-100 63
drive-down-time-to-close 63
drive-up-time-to-100 3
drive-up-time-to-open 64
eventMap off:hoch on:runter open:oben closed:unten
model somfyblinds
room 1_Wohnzimmer
Ist der Modul Entwickler noch aktiv?
Eventuell könnte der die Sendezeit velängern. Also nicht nur mit <repetition> die Wiederholungen steuern sondern auch mit <duration> die Dauer des Sendebefehls.....falls das geht. :-[
Vielen Dank.
Hi,
Es gibt ja grundsätzlich auch noch ein Sendelimit zu beachten.
Hast Du evtl. einen DVB-T USB Stick da und kannst mal nachsehen was Deine Fernbedienung genau sendet, wenn Du 2sec drückst. Ich meine damit wie häufig wird der Befehl gesendet und wie sind die Pausen dazwischen.
Welche CULs oder Signalduinos stehen Dir zur Verfügung?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Ah, okay, verstehe.
Ich habe leider nur einen CUL 868 zur Verfügung.
Vielen Dank für Deine Unterstützung.
Grüße Mave
Hi,
Auch den kann man ja mal kurz(lang)fristig mit der Signalduino Firmware flashen. Das geht seit Dezember im Entwicklungszweig.
https://wiki.fhem.de/wiki/SIGNALduino
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Zitat von: Mave am 04 Mai 2017, 06:43:30
Ist der Modul Entwickler noch aktiv?
Eventuell könnte der die Sendezeit velängern. Also nicht nur mit <repetition> die Wiederholungen steuern sondern auch mit <duration> die Dauer des Sendebefehls.....falls das geht. :-[
Vielen Dank.
ja, der Modulentwickler ist noch aktiv ;)
Den Sendebefehl verlängern ist jetzt eher eine witzige Idee. Das kann ja nicht gehen, denn was soll man denn da senden?
Es ist ja nicht ein einfaches an oder aus, dass man natürlich länger senden kann, sondern es wird eine bestimmte Anzahl von Daten gesendet, die jeweils eine bestimmte Länge haben. An ein Wort kann man jau auch nicht einfach Buchstaben dranhängen, ohne dass der Sinn sich ändert.
Um den Sendebefehl zu verlängern gibt es ja genau die repetition - also die Wiederholung von Kommandos und ich vermute, dass die Fernbedienung auch genau das macht.
Moin viegener,
vielen Dank für Deine Rückmeldung.
Das heißt, ich komme nicht darum herum, auszulesen, was meine FB an Daten schickt, damit die Jalousie dauerhaft fährt....
Grüße Mave
Hallo,
ich betreibe seit längerem meine Somfy-Rolladen mit einm CUL 433. Nun möchte ich aber auch die Handsender so einbinden, dass fhem mitbekommt, wenn der Handsender betätigt wird und so die Rolladen verfahren wwerden.
Ich habe mir einen fhemDuiono besorgt, den ich vmtl. Mit der Firmware für den SinganlDuino flashen muss.
Da meine fhem-Instanz auf einem Cubie läuft und dort schon alle USB-Ports belegt sind, kann ich den SignalDuino nur an einen zweiten Cubie betreiben. Auf dem läuft auch eine fhem – Instanz, nur aber um per sysmon – Modul den Status über fhem2fhem an den ersten Cubie zu übertragen.
Wie bekomme ich nun den Status der Handsender, die auf dem zweiten Cubie empfangen werden so auf den ersten Cubie, dass dort die Rolladen-Instanzen auch die korrekte Position anzeigen, wenn die Rollos per Handsender verfahren werden.
Ich kann mich schwach daran erinnern, das hier schon mal im Forum gelesen zu haben, aber alle Suche war leider vergeblich und im wiki habe ich unter Somfy da auch nichts gefunden.
Danke für weiterführende Infos.
Elektrolurch
Ich empfangen meine Somfy Fernbedienungen auch mit dem 433er CUL, musste nur die Frequenz geringfügig anpassen. Die beiden Devices habe ich dann per Notify verknüpft.
Die Verknüpfung mit dem Fhemduino (oder signalduino, binmir da nichz mehr so sicher) ging wohl mit der Verwendung von Rawdevice. Allerdings war bei mir der Empfangsradius nur etwa 5m :(
Sorry, kleine Korrektur: mein CUL 433 ist mit der Signalduino-FW geflashed
Hallo,
Zitat: Die beiden Devices habe ich dann per Notify
verknüpft
Was hast Du mit dem notify denn beim Rolladen-Device gesetzt? Ohne dass der dann auch ein Sendesignal abgibt?
Ich meine gelesen zu haben, dass es beim sendenen Device ein Attribut gibt, welches die Adressen / Namen der Handsender enthält,
auf dem der Rolladen reagieren soll, also den state ändert. Aber in der Command-Ref steht nichts dazu.
Elektrolurch
Stimmt, das "FHEM-Device" sendet nochmal, das hatte mich aber nur bei den My-Positionen gehindert.
Da ich aber 80% der Rollo-Positionen über Fhem mit % angebe, habe ich die My-Position in allen Rollos gelöscht.
Such mal nach Rawdevice. Das war/ist glaube ich die verknüpfungsmethode die du meinst
Zitat von: Grafkox am 11 Mai 2017, 10:28:21
Ich empfangen meine Somfy Fernbedienungen auch mit dem 433er CUL, musste nur die Frequenz geringfügig anpassen. Die beiden Devices habe ich dann per Notify verknüpft.
Die Verknüpfung mit dem Fhemduino (oder signalduino, binmir da nichz mehr so sicher) ging wohl mit der Verwendung von Rawdevice. Allerdings war bei mir der Empfangsradius nur etwa 5m :(
Sorry, kleine Korrektur: mein CUL 433 ist mit der Signalduino-FW geflashed
Ich habe ebenfalls meinen nanoCUL mit der SIGNALduino FW geflasht. Nach anpassung der Freq auf 433.420MHz kann ich die SOMFY Devices (und IT) wieder schalten. Auch wurde diesmal der Wandtaster mittels autocreate erkannt. Dann wollte ich, dass die Aktivitäten des Wandtasters gelesen werden, um entsprechend das Rolladen-Device anzupassen.
Könnte man dann auch die Position des Rolladen ablesen können? Dafür hatte ich das hier beschriebene notify genutzt. So richtig erschließt mir der Sinn auch noch nicht so ganz. :(
wz_RolladenHandsender:parsestate:.(on|off|stop) {
# <Handsendergerätename> => <FHEM-Gerätename>
my %ger1 = (
"wz_RolladenHandsender" => "wz_Rolladen"
);
my %cmd1 = (
"off" => "open",
"on" => "closed",
"stop" => "go-my"
"prog" => "prog"
);
return undef unless ($ger1{$NAME} and $cmd1{$EVTPART1});
fhem "setreading $ger1{$NAME} state $cmd1{$EVTPART1}";
}
Zitat von: timtom am 14 Mai 2017, 15:04:08
Ich habe ebenfalls meinen nanoCUL mit der SIGNALduino FW geflasht. Nach anpassung der Freq auf 433.420MHz kann ich die SOMFY Devices (und IT) wieder schalten. Auch wurde diesmal der Wandtaster mittels autocreate erkannt. Dann wollte ich, dass die Aktivitäten des Wandtasters gelesen werden, um entsprechend das Rolladen-Device anzupassen.
Könnte man dann auch die Position des Rolladen ablesen können? Dafür hatte ich das hier beschriebene notify genutzt. So richtig erschließt mir der Sinn auch noch nicht so ganz. :(
wz_RolladenHandsender:parsestate:.(on|off|stop) {
# <Handsendergerätename> => <FHEM-Gerätename>
my %ger1 = (
"wz_RolladenHandsender" => "wz_Rolladen"
);
my %cmd1 = (
"off" => "open",
"on" => "closed",
"stop" => "go-my"
"prog" => "prog"
);
return undef unless ($ger1{$NAME} and $cmd1{$EVTPART1});
fhem "setreading $ger1{$NAME} state $cmd1{$EVTPART1}";
}
ZitatSo richtig erschließt mir der Sinn auch noch nicht so ganz.
Damit synchronisierst Du den Handsender mit dem FHEM-Gerät. Wenn Du das nicht machst, dann kann das FHEM-Gerät nicht wissen ob der Rolladen manuell betätigt wurde.
Könnte man dann auch die Position des Rolladen ablesen können?Nein, das gibt das Somfy-Modul noch nicht her.
Zitat von: Ellert am 14 Mai 2017, 20:11:46
Damit synchronisierst Du den Handsender mit dem FHEM-Gerät. Wenn Du das nicht machst, dann kann das FHEM-Gerät nicht wissen ob der Rolladen manuell betätigt wurde.
Könnte man dann auch die Position des Rolladen ablesen können?
Nein, das gibt das Somfy-Modul noch nicht her.
Genau das verstehe ich dann nicht. Was genau weiß das FHEM-Gerät dann und wofür ist das wichtig bzw. kann das genutzt werden? Ich hatte das so verstanden, dass über das notify entsprechend das State Reading im FHEM-Gerät gesetzt wird, sobald eine Taste auf dem Handsender gedrückt wird. Was bringt mir das genau? ;)
Ich war davon ausgegangen, dass dies dann automatisch in die Position umgerechnet wird. Wäre das genau genug, wenn man das manuell machen würde?
Hi,
Du musst die Laufzeiten in den Attributen speichern und dann hast Du auch die berechneten Positionen. Das notify überträgt den Tastendruck auf das FHEM-FB-Device. Das sendet dann auch noch mal die Taste glaub ich. Und kennt dann den korrekten Status inkl. Position.
Also Fahrzeiten messen/stoppen in Sekunden und hinterlegen
Gruß Arnd
Gesendet von meinem SM-G800F mit Tapatalk
Zitat von: RaspiLED am 15 Mai 2017, 09:00:15
Hi,
Du musst die Laufzeiten in den Attributen speichern und dann hast Du auch die berechneten Positionen. Das notify überträgt den Tastendruck auf das FHEM-FB-Device. Das sendet dann auch noch mal die Taste glaub ich. Und kennt dann den korrekten Status inkl. Position.
Also Fahrzeiten messen/stoppen in Sekunden und hinterlegen
Gruß Arnd
Gesendet von meinem SM-G800F mit Tapatalk
Hey, danke. Das ist mir schon klar. Der wz_Rolladen funktioniert ja auch mit allem Pipapo, also Position etc.
Jetzt empfange ich über den neuen SIGNALduino ja auch den zugehörigen Wandtaster. Den hatte ich mittels dem o.g. Notify versucht mit dem Rollladen zu synchronisieren. Das State Reading des Rolladen wird auch nach Druck auf den Handsender angepasst. Die Positionsbestimmung funktioniert jedoch nur, wenn ich den Rolladen über FHEM ansteuer.
Gut und hast Du auch die Zeiten in dem FHEM Device drin?
Zeig mal ein Log bei verbose 4 in beiden FB Devices für eine Fahrt hoch-runter-hoch-mypos ;-)
Es gibt ja auch noch die Variante die normale FB jetzt zu entlernen und nur noch zum schalten der FHEM FB zu nutzen. Aber ich fand den Weg über doppelt senden auch okay ;-)
Gruß Arnd
Gesendet von meinem SM-G800F mit Tapatalk
Zitat von: RaspiLED am 15 Mai 2017, 09:42:41
Gut und hast Du auch die Zeiten in dem FHEM Device drin?
Zeig mal ein Log bei verbose 4 in beiden FB Devices für eine Fahrt hoch-runter-hoch-mypos ;-)
Es gibt ja auch noch die Variante die normale FB jetzt zu entlernen und nur noch zum schalten der FHEM FB zu nutzen. Aber ich fand den Weg über doppelt senden auch okay ;-)
Gruß Arnd
Gesendet von meinem SM-G800F mit Tapatalk
Dein Wunsch ist mir Befehl ;)
Hier erst mal DefinitionenRolladen:
define wz_Rolladen SOMFY 000001
attr wz_Rolladen IODev nanoSIGNALduino
attr wz_Rolladen devStateIcon open:fts_window_2w@black 10:fts_shutter_10 20:fts_shutter_20 30:fts_shutter_30 40:fts_shutter_40 50:fts_shutter_50 60:fts_shutter_60 70:fts_shutter_70 80:fts_shutter_80 90:fts_shutter_90 100:fts_shutter_100 close:fts_shutter_100@black
attr wz_Rolladen drive-down-time-to-100 24
attr wz_Rolladen drive-down-time-to-close 28
attr wz_Rolladen drive-up-time-to-100 4
attr wz_Rolladen drive-up-time-to-open 30
attr wz_Rolladen eventMap on:down stop:stop off:up
attr wz_Rolladen group Rolladenstatus
attr wz_Rolladen room IT,SOMFY,Wohnzimmer
attr wz_Rolladen webCmd stop:down:10:20:30:40:50:60:70:80:90:100:upWandtaster (via autocreate):
define wz_RolladenHandsender SOMFY 612208 AB 157B
attr wz_RolladenHandsender IODev nanoSIGNALduino
attr wz_RolladenHandsender room SOMFY,Wohnzimmer
define FileLog_wz_RolladenHandsender FileLog ./log/wz_RolladenHandsender-%Y.log wz_RolladenHandsender
attr FileLog_wz_RolladenHandsender logtype text
attr FileLog_wz_RolladenHandsender room SOMFYNotify hier aus dem Forum:
define n_RolladenHandsenderSync notify wz_RolladenHandsender:parsestate:.(on|off|stop) {\
# <Handsendergerätename> => <FHEM-Gerätename>\
my %ger1 = (\
"wz_RolladenHandsender" => "wz_Rolladen"\
);;\
\
my %cmd1 = (\
"off" => "open",\
"on" => "closed",\
"stop" => "go-my"\
# "prog" => "prog"\
);;\
\
return undef unless ($ger1{$NAME} and $cmd1{$EVTPART1});;\
fhem "setreading $ger1{$NAME} state $cmd1{$EVTPART1}";;\
}\LogfileRolladen "runter" (via FHEM wz_Rolladen)
2017.05.15 20:45:44 4: SOMFY_set: wz_Rolladen -> entering with mode :send: cmd :on: arg1 :: pos :0:
2017.05.15 20:45:44 4: SOMFY_set: handled command on --> move :on: newState :0:
2017.05.15 20:45:44 4: SOMFY_UpdateState: wz_Rolladen enter with newState:0: updatestate:200: move:on:
2017.05.15 20:45:44 4: SOMFY_UpdateState: wz_Rolladen after conversions newState:0: rounded:0: stateTrans:open:
2017.05.15 20:45:44 4: SOMFY_sendCommand: wz_Rolladen -> cmd :on:
2017.05.15 20:45:44 4: SOMFY_set: wz_Rolladen -> update state in 28 sec
2017.05.15 20:45:47 4: SOMFY_TimedUpdate
2017.05.15 20:45:47 4: SOMFY_UpdateState: wz_Rolladen enter with newState:12.5: updatestate:200: move:on:
2017.05.15 20:45:47 4: SOMFY_UpdateState: wz_Rolladen after conversions newState:12.5: rounded:10: stateTrans:10:
2017.05.15 20:45:47 4: SOMFY_TimedUpdate: wz_Rolladen -> update state in 25 sec
2017.05.15 20:45:50 4: SOMFY_TimedUpdate
2017.05.15 20:45:50 4: SOMFY_UpdateState: wz_Rolladen enter with newState:24.9583333333333: updatestate:200: move:on:
2017.05.15 20:45:50 4: SOMFY_UpdateState: wz_Rolladen after conversions newState:24.9583333333333: rounded:20: stateTrans:20:
2017.05.15 20:45:50 4: SOMFY_TimedUpdate: wz_Rolladen -> update state in 22.01 sec
2017.05.15 20:45:53 4: SOMFY_TimedUpdate
2017.05.15 20:45:53 4: SOMFY_UpdateState: wz_Rolladen enter with newState:37.4166666666667: updatestate:200: move:on:
2017.05.15 20:45:53 4: SOMFY_UpdateState: wz_Rolladen after conversions newState:37.4166666666667: rounded:40: stateTrans:40:
2017.05.15 20:45:53 4: SOMFY_TimedUpdate: wz_Rolladen -> update state in 19.02 sec
2017.05.15 20:45:56 4: SOMFY_TimedUpdate
2017.05.15 20:45:56 4: SOMFY_UpdateState: wz_Rolladen enter with newState:49.875: updatestate:200: move:on:
2017.05.15 20:45:56 4: SOMFY_UpdateState: wz_Rolladen after conversions newState:49.875: rounded:50: stateTrans:50:
2017.05.15 20:45:56 4: SOMFY_TimedUpdate: wz_Rolladen -> update state in 16.03 sec
2017.05.15 20:45:59 4: SOMFY_TimedUpdate
2017.05.15 20:45:59 4: SOMFY_UpdateState: wz_Rolladen enter with newState:62.3333333333333: updatestate:200: move:on:
2017.05.15 20:45:59 4: SOMFY_UpdateState: wz_Rolladen after conversions newState:62.3333333333333: rounded:60: stateTrans:60:
2017.05.15 20:45:59 4: SOMFY_TimedUpdate: wz_Rolladen -> update state in 13.04 sec
2017.05.15 20:46:02 4: SOMFY_TimedUpdate
2017.05.15 20:46:02 4: SOMFY_UpdateState: wz_Rolladen enter with newState:74.7916666666667: updatestate:200: move:on:
2017.05.15 20:46:02 4: SOMFY_UpdateState: wz_Rolladen after conversions newState:74.7916666666667: rounded:70: stateTrans:70:
2017.05.15 20:46:02 4: SOMFY_TimedUpdate: wz_Rolladen -> update state in 10.05 sec
2017.05.15 20:46:05 4: SOMFY_TimedUpdate
2017.05.15 20:46:05 4: SOMFY_UpdateState: wz_Rolladen enter with newState:87.25: updatestate:200: move:on:
2017.05.15 20:46:05 4: SOMFY_UpdateState: wz_Rolladen after conversions newState:87.25: rounded:90: stateTrans:90:
2017.05.15 20:46:05 4: SOMFY_TimedUpdate: wz_Rolladen -> update state in 7.05999999999999 sec
2017.05.15 20:46:08 4: SOMFY_TimedUpdate
2017.05.15 20:46:08 4: SOMFY_UpdateState: wz_Rolladen enter with newState:99.7083333333333: updatestate:200: move:on:
2017.05.15 20:46:08 4: SOMFY_UpdateState: wz_Rolladen after conversions newState:99.7083333333333: rounded:100: stateTrans:100:
2017.05.15 20:46:08 4: SOMFY_TimedUpdate: wz_Rolladen -> update state in 4.06999999999999 sec
2017.05.15 20:46:11 4: SOMFY_TimedUpdate
2017.05.15 20:46:11 4: SOMFY_UpdateState: wz_Rolladen enter with newState:173: updatestate:200: move:on:
2017.05.15 20:46:11 4: SOMFY_UpdateState: wz_Rolladen after conversions newState:173: rounded:150: stateTrans:down:
2017.05.15 20:46:11 4: SOMFY_TimedUpdate: wz_Rolladen -> update state in 1.07999999999999 sec
2017.05.15 20:46:12 4: SOMFY_TimedUpdate
2017.05.15 20:46:12 4: SOMFY_UpdateState: wz_Rolladen enter with newState:200: updatestate:<undef>: move:stop:
2017.05.15 20:46:12 4: SOMFY_UpdateState: wz_Rolladen after conversions newState:200: rounded:200: stateTrans:closed:Rolladen "hoch" (via FHEM wz_Rolladen)
2017.05.15 20:46:24 4: SOMFY_set: wz_Rolladen -> entering with mode :send: cmd :off: arg1 :: pos :200:
2017.05.15 20:46:24 4: SOMFY_set: handled command off --> move :off: newState :200:
2017.05.15 20:46:24 4: SOMFY_UpdateState: wz_Rolladen enter with newState:200: updatestate:0: move:off:
2017.05.15 20:46:24 4: SOMFY_UpdateState: wz_Rolladen after conversions newState:200: rounded:200: stateTrans:closed:
2017.05.15 20:46:24 4: SOMFY_sendCommand: wz_Rolladen -> cmd :off:
2017.05.15 20:46:24 4: SOMFY_set: wz_Rolladen -> update state in 30 sec
2017.05.15 20:46:27 4: SOMFY_TimedUpdate
2017.05.15 20:46:27 4: SOMFY_UpdateState: wz_Rolladen enter with newState:125: updatestate:0: move:off:
2017.05.15 20:46:27 4: SOMFY_UpdateState: wz_Rolladen after conversions newState:125: rounded:150: stateTrans:down:
2017.05.15 20:46:27 4: SOMFY_TimedUpdate: wz_Rolladen -> update state in 27 sec
2017.05.15 20:46:30 4: SOMFY_TimedUpdate
2017.05.15 20:46:30 4: SOMFY_UpdateState: wz_Rolladen enter with newState:92.3461538461538: updatestate:0: move:off:
2017.05.15 20:46:30 4: SOMFY_UpdateState: wz_Rolladen after conversions newState:92.3461538461538: rounded:90: stateTrans:90:
2017.05.15 20:46:30 4: SOMFY_TimedUpdate: wz_Rolladen -> update state in 24.01 sec
2017.05.15 20:46:33 4: SOMFY_TimedUpdate
2017.05.15 20:46:33 4: SOMFY_UpdateState: wz_Rolladen enter with newState:80.8461538461538: updatestate:0: move:off:
2017.05.15 20:46:33 4: SOMFY_UpdateState: wz_Rolladen after conversions newState:80.8461538461538: rounded:80: stateTrans:80:
2017.05.15 20:46:33 4: SOMFY_TimedUpdate: wz_Rolladen -> update state in 21.02 sec
2017.05.15 20:46:36 4: SOMFY_TimedUpdate
2017.05.15 20:46:36 4: SOMFY_UpdateState: wz_Rolladen enter with newState:69.3076923076923: updatestate:0: move:off:
2017.05.15 20:46:36 4: SOMFY_UpdateState: wz_Rolladen after conversions newState:69.3076923076923: rounded:70: stateTrans:70:
2017.05.15 20:46:36 4: SOMFY_TimedUpdate: wz_Rolladen -> update state in 18.02 sec
2017.05.15 20:46:39 4: SOMFY_TimedUpdate
2017.05.15 20:46:39 4: SOMFY_UpdateState: wz_Rolladen enter with newState:57.8076923076923: updatestate:0: move:off:
2017.05.15 20:46:39 4: SOMFY_UpdateState: wz_Rolladen after conversions newState:57.8076923076923: rounded:60: stateTrans:60:
2017.05.15 20:46:39 4: SOMFY_TimedUpdate: wz_Rolladen -> update state in 15.03 sec
2017.05.15 20:46:42 4: SOMFY_TimedUpdate
2017.05.15 20:46:42 4: SOMFY_UpdateState: wz_Rolladen enter with newState:46.3076923076923: updatestate:0: move:off:
2017.05.15 20:46:42 4: SOMFY_UpdateState: wz_Rolladen after conversions newState:46.3076923076923: rounded:50: stateTrans:50:
2017.05.15 20:46:42 4: SOMFY_TimedUpdate: wz_Rolladen -> update state in 12.04 sec
2017.05.15 20:46:45 4: SOMFY_TimedUpdate
2017.05.15 20:46:45 4: SOMFY_UpdateState: wz_Rolladen enter with newState:34.8076923076923: updatestate:0: move:off:
2017.05.15 20:46:45 4: SOMFY_UpdateState: wz_Rolladen after conversions newState:34.8076923076923: rounded:30: stateTrans:30:
2017.05.15 20:46:45 4: SOMFY_TimedUpdate: wz_Rolladen -> update state in 9.05 sec
2017.05.15 20:46:48 4: SOMFY_TimedUpdate
2017.05.15 20:46:48 4: SOMFY_UpdateState: wz_Rolladen enter with newState:23.3076923076923: updatestate:0: move:off:
2017.05.15 20:46:48 4: SOMFY_UpdateState: wz_Rolladen after conversions newState:23.3076923076923: rounded:20: stateTrans:20:
2017.05.15 20:46:48 4: SOMFY_TimedUpdate: wz_Rolladen -> update state in 6.06 sec
2017.05.15 20:46:51 4: SOMFY_TimedUpdate
2017.05.15 20:46:51 4: SOMFY_UpdateState: wz_Rolladen enter with newState:11.8076923076923: updatestate:0: move:off:
2017.05.15 20:46:51 4: SOMFY_UpdateState: wz_Rolladen after conversions newState:11.8076923076923: rounded:10: stateTrans:10:
2017.05.15 20:46:51 4: SOMFY_TimedUpdate: wz_Rolladen -> update state in 3.06999999999999 sec
2017.05.15 20:46:54 4: SOMFY_TimedUpdate
2017.05.15 20:46:54 4: SOMFY_UpdateState: wz_Rolladen enter with newState:0: updatestate:<undef>: move:stop:
2017.05.15 20:46:54 4: SOMFY_UpdateState: wz_Rolladen after conversions newState:0: rounded:0: stateTrans:open:Rolladen "runter" "stop" "doch (via FHEM wz_Handsender). Ich habe den Rolladen jedoch nicht ganz runter gelassen. Weiterhin ist mir aufgefallen, dass ich schon sehr nah am SIGNALduino dran sein muss, damit der Handsender empfangen wird.
2017.05.15 21:02:11 4: SOMFY wz_RolladenHandsender on
2017.05.15 21:02:14 4: SOMFY wz_RolladenHandsender stop
2017.05.15 21:02:37 4: SOMFY wz_RolladenHandsender on
2017.05.15 21:02:40 4: SOMFY wz_RolladenHandsender stopDas Reading position ändert sich nicht, wenn ich über den Wandtaster schalte.
Hi,
Also in den Internals des Handsenders habe ich keine definierten Zeiten erkannt. Dann schaltet der auch nie den State und und triggert keine Notifies, oder? Was passiert, wenn Du die Zeiten auch in die Handfernbedienung einträgst? On, Off, Mypos sollten dann eigentlich gehen nur auf Position fahren müsste zu Fehlern führen...
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Zitat von: RaspiLED am 15 Mai 2017, 21:27:54
Hi,
Also in den Internals des Handsenders habe ich keine definierten Zeiten erkannt. Dann schaltet der auch nie den State und und triggert keine Notifies, oder? Was passiert, wenn Du die Zeiten auch in die Handfernbedienung einträgst? On, Off, Mypos sollten dann eigentlich gehen nur auf Position fahren müsste zu Fehlern führen...
Gruß Arnd
Ok, ich habe jetzt folgendes ergänzt.Allerdings keine Internal, sondern Attr.
attr wz_RolladenHandsender drive-down-time-to-100 24
attr wz_RolladenHandsender drive-down-time-to-close 28
attr wz_RolladenHandsender drive-up-time-to-100 4
attr wz_RolladenHandsender drive-up-time-to-open 30Den zweiten Teil deines Posts habe ich nicht verstanden. Ich habe gedacht, wenn ich den Rolladen über den Handsender (Hardware) steuere, wird der Status bzw. Position in das FHEM Rolladen-Device synchronisiert. Oder etwa nicht?
Hi,
Ja super Attribute mit Zeiten übernommen.
Frage 1) wenn Habdsender benutzt gibt es jetzt auch einen richtigen Status im Handsender Icon/State? 2) Was davon wird per Notify auf das FHEM FB Device übertragen oder wo fehlt es noch?
3) Ist überhaupt etwas anders?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Zitat von: RaspiLED am 16 Mai 2017, 00:55:43
Hi,
Ja super Attribute mit Zeiten übernommen.
Frage 1) wenn Habdsender benutzt gibt es jetzt auch einen richtigen Status im Handsender Icon/State?
Hmm laut log wird nur parsestate gesetzt. Es gibt nur ein "Internal" STATE und kein Reading. Das Internal steht allerdings durchgehend auf ? ? ?
2017-05-13_18:32:20 wz_RolladenHandsender parsestate: off
2017-05-13_18:32:46 wz_RolladenHandsender parsestate: on
2017-05-13_18:49:36 wz_RolladenHandsender parsestate: stopZitat von: RaspiLED am 16 Mai 2017, 00:55:43
2) Was davon wird per Notify auf das FHEM FB Device übertragen oder wo fehlt es noch?
Laut meinem notify wird doch "nur" der State in Form der Begriffe open/closed/go-my/prog im Rolladen-Device gesetzt. Hierbei ist mir die Verwendung von go-my und prog noch unklar. Aber das finde ich noch raus ;)
Zitat von: RaspiLED am 16 Mai 2017, 00:55:43
3) Ist überhaupt etwas anders?
Naja, das Notify setzt den State des Rolladens auf z.B. "go-my" wenn ich auf dem Handsender "stop" drücke. Diesen Status gab es vorher nicht. Daher wird auch kein richtiges Icon angezeigt.
Hallo zusammen,
ich habe mal eine Frage wie Ihr es gelöst habt.
Bei mir gibt es es 2 Geräte:
1. Sender zum Steuern aus fhem heraus
2. Empfänger zum erkennen der Somfy-RTS Fernbedienung
Habe dieser Zur Teit über ein Doif verbunden damit ich auch erkenne wenn die Fernbedienung für die Markise benutzt wurde.
Habe nur das Problem das der beim drücken der Stop/go-my Taste kurz Stoppt und dann den Befehl über fhem bekommt in die go-my position zu fahren.
Im EnOCean Modul gibt dafür extra das attribut SubDef um den virtuellen Schalter mit dem Hardware-Schalter zu verbinden ohne das die Befehle 2mal abgesetzt weden wenn der örtliche benutzt wird.
Virtueller:
Internals:
ADDRESS 000001
CFGFN ./FHEM/fhem_dev_somfy.cfg
DEF 000001
IODev sduino
NAME AU.MARKISE
NR 443
STATE 0 %
TYPE SOMFY
move off
Code:
1 000001
Readings:
2017-05-15 22:00:00 enc_key A0
2017-05-15 22:00:00 exact 0
2017-05-12 19:34:10 parsestate off
2017-05-15 22:00:00 position 0
2017-05-15 22:00:00 rolling_code 0060
2017-05-15 22:00:00 state open
Attributes:
IODev sduino
alias Markise
drive-down-time-to-100 42
drive-down-time-to-close 42
drive-up-time-to-100 0
drive-up-time-to-open 45
eventMap on:Runter off:Hoch go-my:Stop
group Aussen
icon awning
model somfyblinds
room Allgemein
stateFormat {sprintf("%d",ReadingsVal("AU.MARKIESE","position",0))." %"}
webCmd Hoch:Stop:Runter
Fernbedienung:
Internals:
ADDRESS 2CB943
CFGFN ./FHEM/fhem_dev_somfy.cfg
DEF 2CB943 A8 062C
IODev sduino
LASTInputDev sduino
MSGCNT 10
NAME AU.MARKISE.FERN
NR 445
STATE off
TYPE SOMFY
move stop
sduino_DMSG YsA986806D2E97BB
sduino_MSGCNT 10
sduino_RAWMSG MC;LL=-1292;LH=1296;SL=-646;SH=637;D=A986806D2E97BB;C=645;L=56;R=7;
sduino_TIME 2017-05-15 22:00:00
Code:
1 2CB943
Readings:
2017-05-12 12:52:33 enc_key A4
2017-05-12 12:52:33 exact 50
2017-05-15 22:00:00 parsestate off
2017-05-12 12:52:33 position 50
2017-05-12 12:52:33 rolling_code 0648
2017-05-12 12:52:33 state go-my
Attributes:
IODev sduino
model somfyblinds
room SOMFY
stateFormat parsestate
webCmd :
DOIF:
Internals:
DEF ([AU.MARKISE.FERN:parsestate] eq "on")
(set AU.MARKISE Runter)
DOELSEIF
([AU.MARKISE.FERN:parsestate] eq "off")
(set AU.MARKISE Hoch)
DOELSEIF
([AU.MARKISE.FERN:parsestate] eq "stop")
(set AU.MARKISE Stop)
NAME FERNBEDIENUNG_MARKISE
NR 583
NTFY_ORDER 50-FERNBEDIENUNG_MARKISE
STATE cmd_2
TYPE DOIF
Readings:
2017-05-15 22:00:00 Device AU.MARKISE.FERN
2017-05-15 22:00:00 cmd 2
2017-05-15 22:00:00 cmd_event AU.MARKISE.FERN
2017-05-15 22:00:00 cmd_nr 2
2017-05-15 22:00:00 e_AU.MARKISE.FERN_parsestate off
2017-05-15 22:00:00 state cmd_2
Condition:
0 ReadingValDoIf($hash,'AU.MARKISE.FERN','parsestate') eq "on"
1 ReadingValDoIf($hash,'AU.MARKISE.FERN','parsestate') eq "off"
2 ReadingValDoIf($hash,'AU.MARKISE.FERN','parsestate') eq "stop"
Devices:
0 AU.MARKISE.FERN
1 AU.MARKISE.FERN
2 AU.MARKISE.FERN
all AU.MARKISE.FERN
Do:
0:
0 set AU.MARKISE Runter
1:
0 set AU.MARKISE Hoch
2:
0 set AU.MARKISE Stop
3:
Helper:
event parsestate: off
globalinit 1
last_timer 0
sleeptimer -1
timerdev AU.MARKISE.FERN
timerevent parsestate: off
triggerDev AU.MARKISE.FERN
timerevents:
parsestate: off
timereventsState:
parsestate: off
triggerEvents:
parsestate: off
triggerEventsState:
parsestate: off
Internals:
Itimer:
Readings:
0 AU.MARKISE.FERN:parsestate
1 AU.MARKISE.FERN:parsestate
2 AU.MARKISE.FERN:parsestate
all AU.MARKISE.FERN:parsestate
Regexp:
0:
1:
All:
State:
State:
Trigger:
Attributes:
do always
Gibt es da eine elegantere Lösung?
Gruß & Danke
Porsti
Hallo zusammen,
habe jetzt einen SignalDuino im System angeschlossen, auf die aktuellste Firmware geflasht. Er hat auch ein Funkthermometer CUL-tx empfangen und automatisch angelegt. Aber wenn ich mit einer Somfy FB in der Nähe Signale aussende, passiert nichts.
Hier mal die Definitionen:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
STATE opened
TYPE SIGNALduino
version V 3.3.1-dev SIGNALduino - compiled at Jan 3 2017 23:59:32
Attribute:
flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
hardware nano328
verbose 3
whitelist_IDs #
Hier mal den Auszug aus dem log, ab der Stelle, an der er den CUL_tx erkannt hat.
2017.05.16 10:04:25 2: CUL_TX Unknown device 96, please define it
2017.05.16 10:04:25 2: autocreate: define CUL_TX_96 CUL_TX 96
2017.05.16 10:04:25 2: autocreate: define FileLog_CUL_TX_96 FileLog /opt/fhem/log/CUL_TX_96-%Y.log CUL_TX_96
2017.05.16 10:04:25 2: autocreate: define SVG_CUL_TX_96 SVG FileLog_CUL_TX_96:temp4hum4:CURRENT
2017.05.16 10:04:25 3: SignalDuino: Unknown code u63AA4AA8AA90952A12AA, help me!
2017.05.16 10:04:25 3: SignalDuino: Unknown code u6392115524A955254AAA92115524A955254A8, help me!
2017.05.16 10:05:23 3: SignalDuino: Unknown code u63AA4AA8AAA850AA14535495515550A15428A4, help me!
2017.05.16 10:05:23 3: SignalDuino: Unknown code u63AA48455492A554952AAA48455492A554952A, help me!
2017.05.16 10:06:23 3: SignalDuino: Unknown code u63AA4AA8AAA8512A140D52554555428950A04, help me!
2017.05.16 10:06:23 3: SignalDuino: Unknown code u6300000000000000, help me!
2017.05.16 10:07:21 3: SignalDuino: Unknown code u63AA4AA8AAA85152142552554555428A90A10, help me!
2017.05.16 10:07:22 3: SignalDuino: Unknown code u63AA48455492955494A954908AA9252AA92950, help me!
2017.05.16 10:08:19 3: SignalDuino: Unknown code u63AA4AA8AA90A4AA14AA, help me!
2017.05.16 10:08:20 3: SignalDuino: Unknown code u63AA48455492955494A954908AA9252AA92950, help me!
2017.05.16 10:09:18 3: SignalDuino: Unknown code u63AA4AA8AAA8528A1486A92AA2AAA14A28521, help me!
Was muss ich da machen, damit der die Somfy FB erkennt? Ein Attribut zum Umschalten der Frequenz habe ich nicht gefunden....
Wer kann mir da Anschub geben?
Vielen Dank.
Elektrolurch
Zitat von: Elektrolurch am 16 Mai 2017, 10:39:01
Was muss ich da machen, damit der die Somfy FB erkennt? Ein Attribut zum Umschalten der Frequenz habe ich nicht gefunden....
Was bei mir auch so. Schalten hatte funktioniert, nur wurde die FB nicht empfangen. Ich hab einen nanoCUL C1101 auf SIGNALduino FW. Also keinen nano328 wie du.
Ein
set SignalDuino cc1101_freq 433.420hat geholfen.
Leider nicht:
This command is only available with a cc1101 receiver
Kann man da die andere Firmware auch flashen?
Ursprünglich war da ja die fhemDuino - Firmware drauf.
Elektrolurch
Hi,
bei CUL Firmwares mit
set <Dev> freq 433.420
Und zurück hinterher
set <Dev> freq 433.920
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Ist eigentlich mein Notify (siehe oben) richtig? Intuitiv hätte ich nämlich auch eher ein DOIF (ähnlich zu Porsti) gebaut.
Also, ich habe noch mal rumgespielt. Also entweder das Notify ist falsch oder bei mir funktioniert etwas nicht so, wie es soll.
Neben der Def des Handsenders (siehe oben), habe ich drei Readings
enc_key AB 1970-01-01 01:00:00
parsestate off 2017-05-16 20:23:05
rolling_code 157B 1970-01-01 01:00:00
Betätige ich den Handsender, ändert sich nur das parsestate Reading.
Daraufhin reagiert das Notify (siehe oben). Wenn ich z.B. STOP auf dem Handsender drücke, setzt das Notify das Reading state des Rolladen-Devices auf go-my.
Das war's auch schon. Ich verstehe nicht, wie das Rolladen-Device überhaupt an die Position kommen soll :(
Anbei noch mal das List des SIGNALduinos:
Internals:
Clients :IT:CUL_TCM97001:SIGNALduino_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt:FS10:SIGNALduino_un:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL021MXX-if00-port0@57600
DMSG u633EAB4088
DevState initialized
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL021MXX-if00-port0@57600
FD 27
ITClock 250
MSGCNT 41
NAME nanoSIGNALduino
NR 132
NR_CMD_LAST_H 2
PARTIAL
RAWMSG MU;P0=-1354;P1=1223;P2=10940;P3=-22388;P4=566;P5=-735;P6=248;P7=-360;D=2345674045454545101010104510134545454545401545404;CP=4;R=244;
RSSI -80
STATE opened
TIME 1495000011.19051
TYPE SIGNALduino
version V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
Matchlist:
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
11:SD_WS09 ^P9#[A-Fa-f0-9]+
12:SD_WS ^W\d+x{0,1}#.*
13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
14:Dooya ^P16#[A-Fa-f0-9]+
15:SOMFY ^YsA[0-9A-F]+
16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
17:SD_UT ^u30#.*
18:FLAMINGO ^P13#[A-Fa-f0-9]+
19:CUL_WS ^K[A-Fa-f0-9]{5,}
1:IT ^i......
20:Revolt ^r[A-Fa-f0-9]{22}
21:FS10 ^P61#[A-F0-9]+
2:CUL_TCM97001 ^s[A-Fa-f0-9]+
3:SIGNALduino_RSL ^r[A-Fa-f0-9]{6}
4:OREGON ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
5:CUL_TX ^TX..........
6:SD_AS ^P2#[A-Fa-f0-9]{7,8}
7:Hideki ^P12#75[A-F0-9]+
X:SIGNALduino_un ^[u]\d+#.*
QUEUE:
Readings:
2017-05-17 08:44:18 ccconf freq:433.420MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:3173.83Baud)
2017-05-17 08:43:06 config MS=1;MU=1;MC=1
2017-05-17 08:45:51 ping OK
2017-05-17 07:46:51 state opened
2017-05-17 08:43:13 version V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
XMIT_TIME:
1494972060.12981
1494972360.14757
Getcmd:
Keepalive:
ok 0
retry 0
mcIdList:
10
11
12
18
43
47
52
57
58
msIdList:
0
1
13
14
15
17
2
22
23
25
3
32
33
35
38
4
41
51
55
6
7
muIdList:
13.1
16
20
21
24
26
27
28
29
30
31
34
36
37
39
40
44
44.1
45
46
48
49
5
50
56
59
60
61
62
63
64
65
8
9
Attributes:
flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
group Gateway
hardware nanoCC1101
List Rolladen
Internals:
ADDRESS 000001
DEF 000001
IODev nanoSIGNALduino
NAME wz_Rolladen
NR 161
STATE go-my
TYPE SOMFY
move stop
Code:
1 000001
Readings:
2017-05-16 20:08:47 enc_key A4
2017-05-16 20:08:49 exact 0
2017-05-07 15:52:12 parsestate stop
2017-05-16 20:08:49 position 0
2017-05-16 20:08:47 rolling_code 00B4
2017-05-16 20:29:09 state go-my
Attributes:
IODev nanoSIGNALduino
devStateIcon open:fts_window_2w@black 10:fts_shutter_10 20:fts_shutter_20 30:fts_shutter_30 40:fts_shutter_40 50:fts_shutter_50 60:fts_shutter_60 70:fts_shutter_70 80:fts_shutter_80 90:fts_shutter_90 100:fts_shutter_100 down:fts_shutter_100 closed:fts_shutter_100@black
drive-down-time-to-100 24
drive-down-time-to-close 28
drive-up-time-to-100 4
drive-up-time-to-open 30
eventMap on:down stop:stop off:up
group Rolladenstatus
room IT,SOMFY,Wohnzimmer
webCmd stop:down:10:20:30:40:50:60:70:80:90:100:up
List Handsender
Internals:
ADDRESS 612208
DEF 612208 AB 157B
IODev nanoSIGNALduino
LASTInputDev nanoSIGNALduino
MSGCNT 30
NAME wz_RolladenHandsender
NR 186
STATE ???
TYPE SOMFY
move stop
nanoSIGNALduino_DMSG YsAFB1A44B436100
nanoSIGNALduino_MSGCNT 30
nanoSIGNALduino_RAWMSG MC;LL=-1320;LH=1262;SL=-680;SH=610;D=AFB1A44B436100;C=645;L=55;R=23;
nanoSIGNALduino_RSSI -62.5
nanoSIGNALduino_TIME 2017-05-16 20:29:09
Code:
1 612208
Readings:
1970-01-01 01:00:00 enc_key AB
2017-05-16 20:29:09 parsestate stop
1970-01-01 01:00:00 rolling_code 157B
Attributes:
IODev nanoSIGNALduino
drive-down-time-to-100 24
drive-down-time-to-close 28
drive-up-time-to-100 4
drive-up-time-to-open 30
room SOMFY,Wohnzimmer
List Notify
Internals:
DEF wz_RolladenHandsender:parsestate:.(on|off|stop) {
my %ger1 = (
"wz_RolladenHandsender" => "wz_Rolladen"
);
my %cmd1 = (
"off" => "open",
"on" => "closed",
"stop" => "go-my"
);
return undef unless ($ger1{$NAME} and $cmd1{$EVTPART1});
fhem "setreading $ger1{$NAME} state $cmd1{$EVTPART1}";
}
NAME n_RolladenHandsenderSync
NR 188
NTFY_ORDER 50-n_RolladenHandsenderSync
REGEXP wz_RolladenHandsender:parsestate:.(on|off|stop)
STATE 2017-05-16 20:29:09
TYPE notify
Readings:
2017-05-16 18:48:49 state active
Attributes:
ZitatBetätige ich den Handsender, ändert sich nur das parsestate Reading.
Daraufhin reagiert das Notify (siehe oben). Wenn ich z.B. STOP auf dem Handsender drücke, setzt das Notify das Reading state des Rolladen-Devices auf go-my.
Das war's auch schon. Ich verstehe nicht, wie das Rolladen-Device überhaupt an die Position kommen soll
Genau das ist der Sinn des Notifys. Das Notify soll den Status des FHEM-Gerätes nachziehen, nur dann kann man sinnvoll Filter einsetzen im Sinne von
set Rolladen:FILTER=state!=open up. Die Stärke des notifys liegt dort, wo eine größere Zahl von Handsenderbedienungen auf die Status der Geräte übertragen werden soll, weil die Zuordnung Handsender => Rolladen per Hash erfolgt. Bei einem Handsender und einem Rolladen geht es natürlich simpler, auch mit DOIF.
Zitat von: Ellert am 17 Mai 2017, 10:49:39
Genau das ist der Sinn des Notifys. Das Notify soll den Status des FHEM-Gerätes nachziehen, nur dann kann man sinnvoll Filter einsetzen im Sinne von set Rolladen:FILTER=state!=open up. Die Stärke des notifys liegt dort, wo eine größere Zahl von Handsenderbedienungen auf die Status der Geräte übertragen werden soll, weil die Zuordnung Handsender => Rolladen per Hash erfolgt. Bei einem Handsender und einem Rolladen geht es natürlich simpler, auch mit DOIF.
Hmm ok. Bedeutet das dann, dass es gar nicht möglich ist, die Position des Rolladens auszulesen, wenn dieser über den Handsender gesteuert wurde?
Also, ich habe jetzt mal weitergemacht.
Trotz längerer Recherche, ist mir noch nicht ganz klar, was das Attribut "go-my" ist. Könnte mich dazu jemand aufschlauen?
Dann habe ich in FHEM beim Handsender set wz_RolladenHandsender go-my gedrückt. Und siehe da, jetzt sind schon mal die Readings exact, position und state dazugekommen.
Jetzt ist jedoch das Problem, dass der Wert der "position" sich nur ändert, wenn ich in FHEM beim Handsender on/off drücke nicht jedoch wenn ich über den Hardware-Handsender drücke. Weiterhin zählt "position" immer weiter hoch und stoppt nicht bei 100.
Hallo,
leider bin ich noch nicht so weit, da falschen Empfänger gekauft für die Handsender.
Aber ich dachte, mann müsste beim SignalDuino - Somfy Device für den Handsender nur das Attribut rawdevice mit der Adresse des fhem-Somfy-Senders setzen und dann würde es automatisch funktionieren.
Wenn ich mich nicht täusche, dann wurde das Somfy-Modul im notify so erweitert, dass es über die Hardware-Adresse das Signal des Handsenders empfängt und so dann nur den state korrekt ändert, entsprechend der Attribute für die Wegezeiten des Rolladens.
Ein seperates notify ist dann nicht notwendig.
Elektrolurch
Zitat von: Elektrolurch am 19 Mai 2017, 09:24:46
Hallo,
leider bin ich noch nicht so weit, da falschen Empfänger gekauft für die Handsender.
Aber ich dachte, mann müsste beim SignalDuino - Somfy Device für den Handsender nur das Attribut rawdevice mit der Adresse des fhem-Somfy-Senders setzen und dann würde es automatisch funktionieren.
Wenn ich mich nicht täusche, dann wurde das Somfy-Modul im notify so erweitert, dass es über die Hardware-Adresse das Signal des Handsenders empfängt und so dann nur den state korrekt ändert, entsprechend der Attribute für die Wegezeiten des Rolladens.
Ein seperates notify ist dann nicht notwendig.
Elektrolurch
Wenn ich mich nicht irre wird rawdevice nur vom FHEMduino und nicht SIGNALduino unterstützt. Oder hat sich da etwas geändert? Daher besteht mein Problem weiterhin.
Hmm ok. Vielleicht nicht optimal, aber ich habe mir jetzt ein DOIF gebaut, dass den Status entsprechend abbildet. Zwar bekommt der Rolladen alle Befehle 2x ab, aber eine andere Idee habe ich nicht.
([wz_RolladenHandsender:parsestate] eq "on") ##down
(set wz_Rolladen on)
DOELSEIF ([wz_RolladenHandsender:parsestate] eq "off") ##up
(set wz_Rolladen off)
DOELSEIF ([wz_RolladenHandsender:parsestate] eq "stop") ##stop
(set wz_Rolladen stop)
Hallo,
hat jemand Erfahrung ob sich für dieses Modul auch ein toggle realisieren lässt (down/stop/up/stop/....)
Viele Grüße
Pascal
@kalle86: Was meinst Du mit toggle? Benötigst Du einen Befehl, der den Rolladen nach oben fährt, wenn er unten ist und nach oben wenn er unten ist? Das lässt sich vermutlich ganz einfach mit einem dummy device erledigen. Allerdings muss dazu der Status im Rolladen auch entsprechend korrekt sein, sonst werden die falschen Fahrbefehle ausgelöst
Habe das mit dem "setState" so gelöst:
define SomfyFB_1_notify_1 notify SomfyFB_1:parsestate:.(closed|stop|open) setState RolloTer $EVTPART1
define SomfyFB_2_notify_1 notify SomfyFB_2:parsestate:.(closed|stop|open) setState RolloTer $EVTPART1
define Somfy_UHR_notify_1 notify Somfy_UHR:parsestate:.(closed|stop|open) setState RolloTer,RolloWZ $EVTPART1
define SomfyFB_SZ_notify_1 notify SomfyFB_SZ:parsestate:.(closed|stop|open) setState RolloSZ $EVTPART1
Funktioniert soweit sehr gut. Einiges Problem ist der schlechte Empfang des (meines) CC1101. Habe diesen fix auf 433.420Mhz eingestellt und einen 16,5cm Draht angelötet, aber einige commands der Fernbedienungen werden verschluckt.
Wobei die FBs so konfiguriert sind:
define SomfyFB_1 SOMFY 44xxxC xx 0xxx
attr SomfyFB_1 IODev sduino
attr SomfyFB_1 eventMap on:closed off:open
attr SomfyFB_1 room SOMFY
PS: mit diesen Einstellungen funktioniert der Empfang (nur für Somfy) wesentlich zuverlässiger:
freq:433.420MHz bWidth:464KHz rAmpl:42dB sens:16dB
Zitat von: babajun am 24 Mai 2017, 17:19:04
Habe das mit dem "setState" so gelöst:
define SomfyFB_1_notify_1 notify SomfyFB_1:parsestate:.(closed|stop|open) setState RolloTer $EVTPART1
define SomfyFB_2_notify_1 notify SomfyFB_2:parsestate:.(closed|stop|open) setState RolloTer $EVTPART1
define Somfy_UHR_notify_1 notify Somfy_UHR:parsestate:.(closed|stop|open) setState RolloTer,RolloWZ $EVTPART1
define SomfyFB_SZ_notify_1 notify SomfyFB_SZ:parsestate:.(closed|stop|open) setState RolloSZ $EVTPART1
Funktioniert soweit sehr gut. Einiges Problem ist der schlechte Empfang des (meines) CC1101. Habe diesen fix auf 433.420Mhz eingestellt und einen 16,5cm Draht angelötet, aber einige commands der Fernbedienungen werden verschluckt.
Wobei die FBs so konfiguriert sind:
define SomfyFB_1 SOMFY 44xxxC xx 0xxx
attr SomfyFB_1 IODev sduino
attr SomfyFB_1 eventMap on:closed off:open
attr SomfyFB_1 room SOMFY
PS: mit diesen Einstellungen funktioniert der Empfang (nur für Somfy) wesentlich zuverlässiger:
freq:433.420MHz bWidth:464KHz rAmpl:42dB sens:16dB
Aber hat dein Rollladen dann auch dir richtige Position? Diese wird bei mit nämlich nicht im Fernbedienungsdevice gespeichert, wenn ich über die Hardware Fernbedienung steuere.
Es werden die Positionen open - stop - closed angezeigt und auch so das Icon.
Das notify "hört mit", sobald ein command von einer Somfy Fernbedienung ankommt wird mit "setstate" der Status in fhem übernommen.
PS: Die somfy FB habe ich einfach via autocreate angelegt. Der Status der FB in Fhem ist irrelevant da dies ja kein Aktor ist
Zitat von: babajun am 25 Mai 2017, 11:19:39
Es werden die Positionen open - stop - closed angezeigt und auch so das Icon.
Das notify "hört mit", sobald ein command von einer Somfy Fernbedienung ankommt wird mit "setstate" der Status in fhem übernommen.
PS: Die somfy FB habe ich einfach via autocreate angelegt. Der Status der FB in Fhem ist irrelevant da dies ja kein Aktor ist
Das ist schon klar. Aber die Position (z.B. 60%) wird so ja nicht übergeben. Siehe meinen anderen Thread
Zitat von: timtom am 25 Mai 2017, 11:51:33
Das ist schon klar. Aber die Position (z.B. 60%) wird so ja nicht übergeben. Siehe meinen anderen Thread
Verstehe: Du möchtest den Rollo mit der FB runterfahren und willkürlich bei z.B. 60% stoppen - die GUI sollte das wiedergeben. Interessante Frage! Da müsste Fhem ab dem Fahrbefehl mitzählen, die Zeit bis zu "Stop" errechnen um den enprechenden Status anzuzeigen. Dafür habe ich keine Lösung...
Zitat von: babajun am 26 Mai 2017, 20:35:12
Verstehe: Du möchtest den Rollo mit der FB runterfahren und willkürlich bei z.B. 60% stoppen - die GUI sollte das wiedergeben. Interessante Frage! Da müsste Fhem ab dem Fahrbefehl mitzählen, die Zeit bis zu "Stop" errechnen um den enprechenden Status anzuzeigen. Dafür habe ich keine Lösung...
Genau das sollte ja das device eigentlich machen. Aber ich hab das Thema mal entkoppelt
https://forum.fhem.de/index.php/topic,72173.msg638129.html
Hallo,
jetzt habe ich den richtigen SignalDuino mit einem CC1101 Empfänger, aber leider klappt das nicht mit dem Anlernen der Somfy - Handsender.
Hier das setup:
An fhem1 ist ein CUL 433 MHz angeschlossen, mit dem ich schon seit Jahren die Rolladen verfahre. Klappt auch alles wunderbar, nur kann der CUL ja keine Somfy-Signale empfangen.
Am fhem2 ist ein SignalDuino mit einem CC1101 Empfänger angeschlossen.
Attribute:
flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
hardware nanoCC1101
verbose 3
version V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017
und so ist der CC1101 programmiert:
ccconf freq:433.420MHz bWidth:464KHz rAmpl:42dB sens:16dB
(aus Beitrag oben übernommen )
Wenn ich über fhem1 die Rolladen verfahre, empfängt der SignalDuino an fhem2 die Signale und legt per AutoCreate devices vom Typ SOMFY mit IODev SD an. Soweit scheint ja der Empfänger zu funktionieren.
Wenn ich aber eine der Fernbedienungen betätige, geschieht nichts.
Hat da jemand eine Idee?
Stimmen die Parameter des CC1101?
Elektrolurch
Hallo Elektrolurch,
ich hatte das gleiche Problem, und das Anlernen / Empfangen von den Hand-/und Wandsendern ging nur in einem Radius von ca. 1,5 m um den Signalduino.
Ich habe auch unterschiedliche HW-Elemente versucht, aber keine Besserung.
Erst als ich meinen CUL433 MHz mit der Signalduino-FW geflashed habe und die Frequenz auf die der Somfy Geräte geändert habe (geht meines Wissens nur mit dem CUL und nicht mit der Signalduino HW), empfange ich nun alle Original-Sender im ganzen Haus.
Gruß
Thorsten
Hallo Thorsten,
das ist alles etwas merkwürdig, denn der SignalDuino befindet sich im Keller und empfängt die Somfy-Signale, die fhem1 vom Speicher aus sendet, aber nicht die Handsender.
Ich habe mal ein paar der Handsender mit in den Keller genommen und einen davon hat der SD dann sporadisch empfangen.
Zitat:
Erst als ich meinen CUL433 MHz mit der Signalduino-FW geflashed habe und die Frequenz auf die der Somfy Geräte geändert habe (geht meines Wissens nur mit dem CUL und nicht mit der Signalduino HW),
Ich habe eigentlich ja einen mit dem CC1101 - Chip und der behauptet ja, er könne die Frequenz varieren.
Auf 433.920 empfängt das Teil im Keller alle möglichen Signale aus der Nachbarschaft, u.a. ein Thermometer TCM mit 3.2 Grad. Ob das im Kühlschrank bei jemandem liegt?
Ok. Ich könnte ja den CUL 433 MHz ja mal mit der SignalDuino - Firmware flashen und die beiden Teile tauschen....
Hat da jemand noch so ähnliche Erfahrungen gemacht oder noch eine andere Idee?
Elektrolurch
Also ich hatte ja meinen nanoCUL von der aculfw auf die SIGNALduino-FW geflasht. Hat soweit auch alles prima geklappt. Per autocreate hatte allerdings der nanoCUL@aculfw viel mehr erkannt. Übrigens auch ein 2-3 Grad Thermometer ;)
Vergleich mal meine Listings: https://forum.fhem.de/index.php/topic,25321.msg636265.html#msg636265
Ich hatte - genau wie du - dann irgendwann die Freq auf SOMFY umgestellt. Dann wurde der Wandtaster auche rst per autocreate erkannt, als ich ihn direkt neben dem CUL betätigt hatte. Dabei musste ich den Taster etwas länger gedrückt halten 1-2 Sek. Nachdem er erkannt wurde, reagiert er auch, wenn er etwas weiter entfernt ist. Jedoch nicht 100% zuverlässig. Schalten über FHEM geht jedoch super.
...wie oben geschrieben, mit folgenen Paramtern hatte ich die besten Empfangsergebnisse:
ccconf freq:433.420MHz bWidth:464KHz rAmpl:42dB sens:16dB
Antenne ist ein 16,5cm Draht stehend. Liegend war dem Emfpang spürbar schlechter.
Ich hab mir nu auch einen sduino cul mul c1101 gebaut und geflasht.
Schon wäre wenn der Empfang wie beim fhemduino ans fhem device geleitet werden würde.
So das der Status dort auch aktualisiert wird.
Gesendet von meinem SM-G935F mit Tapatalk
Guten Morgen,
ich habe gestern meinen SIGNALduino mit cc1101 auf die Somfy Frequenz 433.42 eingestellt und die Somfy Fernbedienung betätigt - und zwar für alle 3 Jalousien einzelnen und noch für alle 3 Jalousien gleichzeitig. FHEM hat mir daraufhin brav 4 Somfy Devices angelegt. Mit "repetition=30" kann ich jetzt alle Jalousien problemlos steuern.
Ich hatte vor ein paar Tagen schonmal FHEM über meinen CUL868 mit den Somfy Jalousien gekoppelt, konnte die Jalousien aber trotz vielen Versuchen mit repetition nicht am Stück hoch oder runterfahren lassen - sie haben sich immer nur für ein paar Millimeter bewegt.
Jetzt meine Fragen:
1) Ist FHEM mit den Jalousien noch immer gekoppelt, obwohl ich vom CUL868 auf den neuen SIGNALduino gewechselt bin oder simuliert/emuliert FHEM jetzt die original Fernbedienung, weil ich ja quasi die Verbindung FB <-> Somfy durch das "Abhören" gekapert habe?
2) Mit der original FB kann ich die Jalousien nicht mehr ohne Weiteres steuern. Erst wenn ich mehrfach die Knöpfe auf der FB betätige und damit den rolling-code erhöhe, funktioniert irgendwann auch mal wieder die original FB. Umgekehrt lassen sich dann aber die Jalousien mit FHEM wieder erst nach mehrmaligem triggern zu einer Bewegung animieren.
Gibt es eine Möglichkeit, die Jalousien mit FHEM UND der FB gleichzeitig zu steuern?
Vielen Dank für Eure Unterstützung.
Grüße Mave
Wenn das FHEM-Gerät mit der selben Adresse, wie die FB arbeitet, dann stören sie sich gegenseitig, wie Du selbst beobachtet hast.
Du müsstest für jede benutzte FB-Adresse ein FHEM-Gerät mit einer von Dir festgelegten Adresse erstellen und diese FHEM-Geräte an die entsprechende Somfy-Hardware anlernen, so wie Du es mit einer FB machst.
FB-Adresse ABCDE0 angelernt auf Rollo1
FHEM-Gerät zum Empfang der FB mit Adresse ABCDE0 (Status des Rollo1 wenn über FB bedient) Dieses Gerät kann als Dummydevice (nicht als Dummy) konfiguriert werden, das es Rolo1 nicht bedienen soll (vermeiden des Rolling Code Konflikts)
FHEM-Gerät als virtuelle FB mit der selbst vergebenen Adresse FAFAF0 (anlernen auf Rollo1)
Damit das FHEM-Gerät (FAFAF0) den richtigen Status anzeigt muss der Status des FHEM-Gerät (ABCDE0) in parsestate über ein DOIF oder notify auf das FHEM-Gerät (FAFAF0) mit setreading Somfy_FAFAF0 state [Somfy_ABCDE0:parsestate] übertragen werden.
Hi,
nur für Dein Verständnis: Somfy benutzt Rolling Codes - also wird bei jedem Tastendruck ein Zähler um eins erhöht. Wenn man zu alte Rolling Codes sendet bewegt sich die Rollade deswegen nicht mehr. Warum? Das ist ein Sicherheitsfeature und verhindert sogenannte Replay-Attacken!
Der Beitrag vorher erklärt daher richtigerweise den Weg mittels FHEM FB und zweiter Hand FB!
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Zitat von: Ellert am 03 Juni 2017, 08:58:24
Wenn das FHEM-Gerät mit der selben Adresse, wie die FB arbeitet, dann stören sie sich gegenseitig, wie Du selbst beobachtet hast.
Du müsstest für jede benutzte FB-Adresse ein FHEM-Gerät mit einer von Dir festgelegten Adresse erstellen und diese FHEM-Geräte an die entsprechende Somfy-Hardware anlernen, so wie Du es mit einer FB machst.
FB-Adresse ABCDE0 angelernt auf Rollo1
FHEM-Gerät zum Empfang der FB mit Adresse ABCDE0 (Status des Rollo1 wenn über FB bedient) Dieses Gerät kann als Dummydevice (nicht als Dummy) konfiguriert werden, das es Rolo1 nicht bedienen soll (vermeiden des Rolling Code Konflikts)
FHEM-Gerät als virtuelle FB mit der selbst vergebenen Adresse FAFAF0 (anlernen auf Rollo1)
Damit das FHEM-Gerät (FAFAF0) den richtigen Status anzeigt muss der Status des FHEM-Gerät (ABCDE0) in parsestate über ein DOIF oder notify auf das FHEM-Gerät (FAFAF0) mit setreading Somfy_FAFAF0 state [Somfy_ABCDE0:parsestate] übertragen werden.
Hey Ellert,
vielen Dank für Deine Hilfestellung.
Leider verstehe ich noch nicht ganz, wie ich das jetzt umsetzen soll.
Wärst Du bitte so lieb und schreibst nochmal für einen Newbie, was er genau tun muß.
Vielen Dank im Voraus.
Grüße Mave
Zitat von: Mave am 03 Juni 2017, 11:59:53
Hey Ellert,
vielen Dank für Deine Hilfestellung.
Leider verstehe ich noch nicht ganz, wie ich das jetzt umsetzen soll.
Wärst Du bitte so lieb und schreibst nochmal für einen Newbie, was er genau tun muß.
Vielen Dank im Voraus.
Grüße Mave
Was konkret verstehst Du nicht, hinsichtlich der Umsetzung? Und was hast Du schon selbst versucht, um das Verständnis zu erlangen?
Die Steuerung über FB und FHEM habe ich jetzt hinbekommen.
Mir fehlt jetzt noch die Anzeige des Status in FHEM, wenn ich die FB verwende.
Grüße Mave
Antwort #346: Letzter Satz.
Naja, wohl eher #347 letzter Satz ;-)
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Zitat von: Ellert am 03 Juni 2017, 08:58:24
Wenn das FHEM-Gerät mit der selben Adresse, wie die FB arbeitet, dann stören sie sich gegenseitig, wie Du selbst beobachtet hast.
Du müsstest für jede benutzte FB-Adresse ein FHEM-Gerät mit einer von Dir festgelegten Adresse erstellen und diese FHEM-Geräte an die entsprechende Somfy-Hardware anlernen, so wie Du es mit einer FB machst.
FB-Adresse ABCDE0 angelernt auf Rollo1
FHEM-Gerät zum Empfang der FB mit Adresse ABCDE0 (Status des Rollo1 wenn über FB bedient) Dieses Gerät kann als Dummydevice (nicht als Dummy) konfiguriert werden, das es Rolo1 nicht bedienen soll (vermeiden des Rolling Code Konflikts)
FHEM-Gerät als virtuelle FB mit der selbst vergebenen Adresse FAFAF0 (anlernen auf Rollo1)
Damit das FHEM-Gerät (FAFAF0) den richtigen Status anzeigt muss der Status des FHEM-Gerät (ABCDE0) in parsestate über ein DOIF oder notify auf das FHEM-Gerät (FAFAF0) mit setreading Somfy_FAFAF0 state [Somfy_ABCDE0:parsestate] übertragen werden.
Genau das Vorgehen verstehe ich ebenfalls nicht (wie auch hier beschrieben: https://forum.fhem.de/index.php/topic,72173.0.html)
Mein Problem ist, dass beim Betätigen der FB eben nicht die genaue Position (z.B. 30%) im Status vorgehalten wird, sondern eben nur on/off/stop. Daher funktioniert auch die Übergabe per parsestate nur, wenn der Rolladen komplett offen oder geschlossen ist. Oder habe ich ein Fehler im Define?
Zitat von: timtom am 05 Juni 2017, 16:42:33
Genau das Vorgehen verstehe ich ebenfalls nicht (wie auch hier beschrieben: https://forum.fhem.de/index.php/topic,72173.0.html)
Mein Problem ist, dass beim Betätigen der FB eben nicht die genaue Position (z.B. 30%) im Status vorgehalten wird, sondern eben nur on/off/stop. Daher funktioniert auch die Übergabe per parsestate nur, wenn der Rolladen komplett offen oder geschlossen ist. Oder habe ich ein Fehler im Define?
Somfy kann, soweit ich weiss nur up, down, stop, und programm, mehr nutze ich auch nicht. Wenn das FHEM-Gerät auf dem der Handsender abgestützt ist Events für Prozentwerte liefert, dann könnt man die auch auf das 2. FHEM-Gerät übertragen, aber ob das so ist, weiss ich nicht.
Vielleicht klappt es über einen Umweg 1. Fhem-Gerät (Handsenderempfang: up,down,stop) per notify/DOIF und set-Befehl auf 2.FHEM-Gerät (Dummydevice) darauf ein notify/DOIF, dass per setreading die %-Werte auf das 3.FHEM-Gerät (angelernt auf Rolladen) überträgt, so als Idee.
Zitat von: Ellert am 05 Juni 2017, 20:17:43
Somfy kann, soweit ich weiss nur up, down, stop, und programm, mehr nutze ich auch nicht. Wenn das FHEM-Gerät auf dem der Handsender abgestützt ist Events für Prozentwerte liefert, dann könnt man die auch auf das 2. FHEM-Gerät übertragen, aber ob das so ist, weiss ich nicht.
Vielleicht klappt es über einen Umweg 1. Fhem-Gerät (Handsenderempfang: up,down,stop) per notify/DOIF und set-Befehl auf 2.FHEM-Gerät (Dummydevice) darauf ein notify/DOIF, dass per setreading die %-Werte auf das 3.FHEM-Gerät (angelernt auf Rolladen) überträgt, so als Idee.
Also die Prozentwerte (im STATE) werden nach Pflege der Attribute (z.B. drive-down-time-to-100) ja von FHEM berechnet. Allerdings anscheinend nur, wenn man das Rolladen-FHEM-Device oder das FB-FHEM-Device über FHEM betätigt. Betätige ich die FB-Hardware, ändert sich im FB-FHEM-Device nur der Status nach on/off/go-my.
Daher habe ich als Workaround ja das DOIF, dass einfach ein SET an das Rolladen-FHEM-Device, sobald die FB-Hardware betätigt wird. Dann wird zwar 1 Funksignal durch die FB-Hardware an den Rolladen gesendet und noch 1 Funksignal über das SET des Rolladen-FHEM-Device. Anders habe ich das aber bisher nicht hinbekommen.
Hi,
Daher mein Vorschlag noch ein drittes Somfy Device zu nutzen, dass nicht gepaired ist und daher auch keine doppelte Auslösung macht. Jeweils ein Doif von dem FB Somfy oder dem FHEM Somfy an das dritte, welches nur als Statusanzeige verwendet wird. Dann kann man aber mit diesem Device nicht schalten (sonst wäre es ein Zirkelschluss). Hat jemand eine bessere Idee? Oder eine myutils routine, die das FHEM Somfy Device nur senden lösst, falls vorher keine Änderung an dem FB Somfy stattgefunden hat!?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Zitat von: Ellert am 04 Juni 2017, 12:25:54
Antwort #346: Letzter Satz.
Vielen Dank.
Mir fehlt im Moment noch das Verständnis, wie man dieses Dummydevice (nicht Dummy) anlegt.
Hi,
Ich habe in einem anderen Thread etwas zu Readingsproxy gelesen, könnte uns das helfen?
Gruß Arnd
Gesendet von meinem SM-G800F mit Tapatalk
Zitat von: Mave am 09 Juni 2017, 06:21:18
Vielen Dank.
Mir fehlt im Moment noch das Verständnis, wie man dieses Dummydevice (nicht Dummy) anlegt.
Um bei diesem Beispiel zu bleiben https://forum.fhem.de/index.php/topic,25321.msg643319.html#msg643319
müsstest Du im Gerät
Somfy_ABCDE0 (Empfang des Handsenders) das Attribut "dummy" auf 1 setzen.
Okay, danke.
Hallo Modul-Entwickler!
Was haltet ihr/du von dem Vorschlag vom Elektrolurch um SOMFY Fernbedienungen einfacher mit den Rollladen abzugleichen?
https://forum.fhem.de/index.php/topic,72173.msg653940.html#msg653940
Gruß, Stefan.
Seit ein paar Tagen haben wir eine neue Markise mit SOMFY RTS Fernbedienung.
Die Markise habe ich nun auch über ein CUL 433 erfolgreich eingebunden.
Zusätzlich kann über die Markisenfernbedienung auf dem 2. Kanal noch eine dimmbare LED-Lichtleiste an der Markise gesteuert werden. Diese habe ich zwar auch über das SOMFY Modul in FHEM einbinden können, das Verhalten ist aber "gewöhnungsbedürftig", da das Modul die Leiste wie eine Markise ansteuert.
Aktuell ist das Verhalten so:
LED-Leiste aus: "Off" schaltet die LED Leiste ein auf niedrigster Dimmstufe.
LED-Leiste an: "Off" schaltet jeweils eine Dimmstufe Heller.
LED-Leiste an: "On" schaltet jeweils eine Dimmstufe Dunkler (bis irgendwann die Leiste wieder aus ist).
Auf der Original-Fernbedienung verhält sich das etwas anders:
Kurzer Druck auf "Pfeil-hoch": Die LED Leiste wird auf maximale Helligkeit eingeschaltet.
Kurzer Druck auf "Pfeil-runter": Die LED Leiste wird ausgeschaltet.
Langer Druck auf "Pfeil hoch": Die LED Leiste wird ein- und stufenweise heller geschaltet, bis man die Taste loslässt.
Langer Druck auf "Pfeil runter": Die LED Leiste wird stufenweise dunkler und dann aus geschaltet.
Bekommen wir dieses Verhalten irgendwie in das Modul übertragen?
Praktisch würde es mir erst mal reichen, wenn ich über FHEM einfach nur "Licht maximal ein" und "Licht aus" schalten könnte. Einzelne Dimmstufen sind erst mal nicht notwendig. Man müsste das also nur so konfiguriert bekommen, dass das SOMFY Modul sich bei "on" und "off" wie ein einfacher kurzer Druck auf der Fernbedienung verhält.
Hi,
Mit eventmap on off tauschen und dann mit notify das event einfach 6 mal wiederholen ;-)
Dann tippst Du einmal on und es wird 6 Stufen dunkler!
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
So leute! Ich kenn mich nach lesen des threads nicht mehr aus!
Ich habe somfy markise mit fhem über signalduino cc1101 gepairt!
Die handfernbedienung ist mit autocreat angelernt!
Wie geht es jetzt weiter, das ich den Status der fernbedienung in fhem übertragen wird?
Dazu gibt es einen eigene Rubrik.
https://forum.fhem.de/index.php/topic,72173.msg638129.html
Allerdings erkennt der SignalDuino die Somfy-Signale der FBs leider z.Z. noch nicht einwandfrei, so dass der Status nicht immer stimmt.
Außerdem gibt es in dem Beitrag eine modifizierte Version vom Somfy-Modul, mit der die Koppelung über ein Attribut erst möglich ist, aber nur zum Testen.
Zitat:
...ich kenn mich nicht aus....
Dann erst einmal lesen.
Elektrolurch
danke für die Anweisung zum lesen Elektrolurch! Hab ich alles gelesen, und es ist mehr und mehr verwirrender geworden mit notify rawdevice un d dann wieder dummy dann wieder mit Positionen usw. drum habe ich gefragt!
Hi,
Mapping Somfy Hand Fernbedienung auf FHEM Somfy Device ist genau dieser Post:
https://forum.fhem.de/index.php?topic=72173.msg653940#msg653940
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Ich habe ein Problem. Seit gestern bekomme ich
2017.08.02 21:38:41 1: ERROR: >Somfy RTS message format error!< returned by the SOMFY ParseFn is invalid, notify the module maintainer
2017.08.02 21:38:52 1: ERROR: >Somfy RTS checksum error!< returned by the SOMFY ParseFn is invalid, notify the module maintainer
und ich weiß jetzt nicht, was ich genau tun soll.
Schön. Benutzt Du einen SignalDuino, um die Handsender der Rolladen zu empfangen? Ein paar Infos mehr wären schön nützlich....
Elektrolurch
Sorry, war verpeilt:
Internals:
Clients :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt:FS10:SIGNALduino_un:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A104WS3F-if00-port0
DMSG u63DF5BBB5AB5BAB55DAD6EF76EAE8
DevState initialized
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A104WS3F-if00-port0@57600
FD 11
LASTDMSG u63DF5BBB5AB5BAB55DAD6EF76EAE8
MSGCNT 3453
NAME sduino
NR 22
NR_CMD_LAST_H 1
PARTIAL
RAWMSG MU;P0=-28324;P1=644;P2=1942;P3=-3919;P4=-1950;D=0102324232323232424232423232423232423242423242424232424232423232424242324242424232324232424232424232423232423232324232324232423232424242323242;CP=2;R=24;
RSSI -62
STATE opened
TIME 1501747675
TYPE SIGNALduino
sendworking 0
unknownmessages
version V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
DoubleMsgIDs:
MatchList:
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
11:SD_WS09 ^P9#F[A-Fa-f0-9]+
12:SD_WS ^W\d+x{0,1}#.*
13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
14:Dooya ^P16#[A-Fa-f0-9]+
15:SOMFY ^Ys[0-9A-F]+
16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
17:SD_UT ^u30#.*
18:FLAMINGO ^P13#[A-Fa-f0-9]+
19:CUL_WS ^K[A-Fa-f0-9]{5,}
1:IT ^i......
20:Revolt ^r[A-Fa-f0-9]{22}
21:FS10 ^P61#[A-F0-9]+
2:CUL_TCM97001 ^s[A-Fa-f0-9]+
3:SD_RSL ^P1#[A-Fa-f0-9]{8}
4:OREGON ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
5:CUL_TX ^TX..........
6:SD_AS ^P2#[A-Fa-f0-9]{7,8}
7:Hideki ^P12#75[A-F0-9]+
X:SIGNALduino_un ^[u]\d+#.*
QUEUE:
READINGS:
2017-06-26 16:33:12 ITParms Unsupported command
2017-08-01 11:12:44 ccconf freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)
2017-08-01 11:12:51 ccpatable C3E = 00 C0 00 00 00 00 00 00 => 10_dBm
2017-06-26 16:53:00 ccreg C3E = 00 84 00 00 00 00 00 00
2017-06-26 16:33:08 config MS=1;MU=1;MC=1
2017-08-03 02:34:57 ping OK
2017-08-01 11:11:22 raw ccFactoryReset done
2017-08-01 10:17:22 state opened
2017-08-01 10:17:22 version V 3.3.1-dev SIGNALduino cc1101 - compiled at Mar 10 2017 22:54:50
XMIT_TIME:
1501707660
getcmd:
keepalive:
ok 0
retry 0
mcIdList:
10
11
12
18
43
47
52
57
58
msIdList:
0
1
13
14
15
17
2
22
23
25
3
32
33
35
38
4
41
51
55
6
68
7
muIdList:
13.1
16
20
21
24
26
27
28
29
30
31
34
36
37
39
40
44
44.1
45
46
48
49
5
50
56
59
60
61
62
63
64
65
66
67
8
9
Attributes:
alias SIGNALduino
devStateIcon Initialized:cul_usb@green:Open Open:cul_usb@red:Initialized
flashCommand avrdude -c arduino -b 57600 -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
group Haus
hardware nanoCC1101
verbose 2
und angelegt wurde zum Beispiel
Internals:
ADDRESS 467FA4
CFGFN
DEF 467FA4 A2 0168
IODev miniCUL
LASTInputDev sduino
MSGCNT 3
NAME SOMFY_467FA4
NR 3925
STATE ???
TYPE SOMFY
move stop
sduino_DMSG YsA6B6B7D97D0244
sduino_MSGCNT 3
sduino_RAWMSG MC;LL=-1313;LH=1252;SL=-674;SH=612;D=A6B6B7D97D0244;C=641;L=55;R=236;
sduino_RSSI -84
sduino_TIME 2017-08-02 22:03:11
CODE:
1 467FA4
READINGS:
1970-01-01 01:00:00 enc_key A2
2017-08-02 22:03:11 parsestate stop
1970-01-01 01:00:00 rolling_code 0168
Attributes:
IODev miniCUL
wobei miniCUL falsch ist, denn der empfängt auf 868:
Internals:
CMDS
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
DEF 192.168.2.3:23 0000
DeviceName 192.168.2.3:23
FHTID 0000
NAME miniCUL
NR 69
PARTIAL
STATE opened
TYPE CUL
initString X21
MatchList:
1:USF1000 ^81..(04|0c)..0101a001a5ceaa00....
2:BS ^81..(04|0c)..0101a001a5cf
3:FS20 ^81..(04|0c)..0101a001
4:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
5:KS300 ^810d04..4027a001
6:CUL_WS ^K.....
7:CUL_EM ^E0.................$
8:HMS ^810e04....(1|5|9).a001
9:CUL_FHTTK ^T[A-F0-9]{8}
A:CUL_RFR ^[0-9A-F]{4}U.
B:CUL_HOERMANN ^R..........
C:ESA2000 ^S................................$
D:CUL_IR ^I............
E:CUL_TX ^TX[A-F0-9]{10}
F:Revolt ^r......................$
G:IT ^i......
H:STACKABLE_CC ^\*
I:UNIRoll ^[0-9A-F]{5}(B|D|E)
J:SOMFY ^Y[r|t|s]:?[A-F0-9]+
K:CUL_TCM97001 ^s[A-F0-9]+
L:CUL_REDIRECT ^o+
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2017-08-01 10:57:17 raw No answer
2017-08-01 10:56:34 state opened
Attributes:
group Haus
verbose 0
Das Listing bringt jetzt wenig, da immer noch nicht klar ist, was Du seitens Somfy mit dem SignalDuino empfangen möchtest. Aber soweit als Info:
Die SignalDuino firmware hat Probleme mit dem empfang von Somfy-Signalen. Offensichtlich gehen da bits schon mal verloren, dann kommen diese Fehlermeldungen zu Stande oder es werden jede Menge neue Somfy-Devices angelegt.
Außerdem kann man nicht alle Handsender von Somfy mit dem eingecheckten Somfy-Modul empfangen, da ist die Abfrage auf das Format des Signals so restriktiv, dass da einige Handsender gar nicht erkannt werden.
Ich habe das Modul lokal bei mir diesbezüglich angepasst, konnte aber dem Empfangsproblem noch nicht auf den Grund gehen...
Elektrolurch
Ich verstehe (hoffentlich), danke. Ich will gar nicht Somfy empfangen, sondern wirklich nur ansteuern. Ich kenne das Problem mit dem rolling code und habe die entsprechenden autodevices einfach auf "hidden" gestellt. Und versuche, mit einem neu erstellten device auch zu arbeiten.
Insofern ignoriere ich die autodevices. Inwiefern kann dann aber das Modul die Signale nicht verarbeiten? Das ist ja etwas anderes, da scheinen unverständliche Nachrichten anzukommen.
Ich habe automatische Rollos von Somfy, die ich normalerweise nur rauf oder runter setze. Ganz unspektakulär. Ich will das nur auch von außerhalb machen lassen, deshalb nutze ich FHEM.
Zitat:
Inwiefern kann dann aber das Modul die Signale nicht verarbeiten? Das ist ja etwas anderes, da scheinen unverständliche Nachrichten anzukommen.
1. SignalDuino empfängt Signal, z.B. vom Wandsender
2. Er stellt fest, dass ist ein Somfy
3. Er ruft Somfy_ParseFN auf.
4. Das Modul kann das Signal nicht korrekt decodieren -> Fehler im log -> fertig
5. Das Modul kann das Signal verarbeiten und stellt fest, dass das device noch nicht vorhanden ist: Es wird autocreate aufgerufen
6. Es kennt das device, dann wird der state gesetzt und fhem über notify informiert.
Wenn man die ständigen Meldungen / neuen devices verhindern will und sein System ja eh fertig ist:
attr autocreate disable 1
Elektrolurch
OK, dann mache ich das. Aber besteht hier nicht ein Fehler im Somfy-Modul, das der Entwickler beheben kann/soll und wir sollen ihm dabei helfen? So hatte ich den Logeintrag verstanden.
Hi andies,
Ich sehe das ganz anders!
Dein Signalduino steht auf 433.92
MHz. Der hört also IT Steckdosen oder Alarmanlagen oder ... vom Nachbarn!
Un Deine Somfies zu hlren müsste der auf 433.42 MHz stehen
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Sender und Empfänger waren Ca 2m entfernt, da hört der sifnalduino schon mit. Mir ist gerade was eingefallen: ich habe eine weitere Fernbedienung angelernt. Könnte es sein, dass der signalduino dieses Anlernsignal nicht verstanden hat?
Gesendet von iPhone mit Tapatalk Pro
Es geht nicht um die Entfernung! Sondern die Frequenz!
433.920+-0.325 er hört also von 433.595 bis 434.245
Aber von einem Sender auf 433.420 hört er nur noch Abstruses am Rand!
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
ZitatAber besteht hier nicht ein Fehler im Somfy-Modul, das der Entwickler beheben kann/soll und wir sollen ihm dabei helfen? So hatte ich den Logeintrag verstanden.
Ja, dies ist ein bekannter Fehler:
sub SOMFY_Parse($$) {
...
if ($ioType eq "SIGNALduino") {
my $encData = substr($msg, 2);
return "Somfy RTS message format error!" if ($encData !~ m/A[0-9A-F]{13}/);
my $decData = SOMFY_RTS_Crypt("d", $name, $encData);
my $check = SOMFY_RTS_Check($name, $decData);
return "Somfy RTS checksum error!" if ($check ne substr($decData, 3, 1));
...
Es gibt eine angepasste Version die die Fehler zumindest teilweise behebt. Ich kann den link dazu aber gerade nicht finden
if ($ioType eq "SIGNALduino") {
my $encData = substr($msg, 2);
if ($encData !~ m/[0-9A-F]{14}/) {
Log3 $name, 4, "$name: Somfy_Parse: RTS message format error!";
return "";
}ZitatWenn man die ständigen Meldungen / neuen devices verhindern will
Evtl bringt ein autocreateThreshold was.
$hash->{AutoCreate}=
{ "SOMFY.*" => { GPLOT => "", FILTER => "%NAME", autocreateThreshold => "2:30"} };https://forum.fhem.de/index.php/topic,58397.msg642137.html#msg642137
https://forum.fhem.de/index.php/topic,64141.msg650435.html#msg650435
Gruß Ralf
Ich habe seit heute ein Problem mit meinen Somfy Rollläden.
Seit heute Abend fahren meine Rollläden in Abständen von etwa 10 Min rauf und runter.
Im Logfile erhalte ich folgende Fehlermeldung:
2017.08.03 21:44:19 1: SOMFY_CalcCurrentPos: rollo_OG_Z2_tuer move wrong stop
An den Somfy Rollläden habe ich seit Monaten nichts verändert, lediglich an meiner Rollladenautomatisierung gearbeitet. Sobald ich diese disable bleibt der Rollladen auch brav unten.
Habt ihr einen Rat für mich?
List mal was du hast! Unsere Glaskugeln sehen einen Fehler im Nebel !-)
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Zitat von: RaspiLED am 03 August 2017, 22:08:08
Es geht nicht um die Entfernung! Sondern die Frequenz!
Meinst Du, dass ich die 325kHz mal erhöhe? Oder bringt das nix, weil das Problem, das Ralf9 erwähnt, damit nicht gelöst wird?
Gesendet von iPhone mit Tapatalk Pro
Bitteschön und danke vorab für die schnelle Hilfe :)
Internals:
ADDRESS 000002
CUL_0_MSGCNT 48
CUL_0_RAWMSG YsAA4F08BA020000
CUL_0_TIME 2017-08-03 22:15:40
DEF 000002
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 48
NAME rollo_wz_2_tuer
NR 43
STATE closed
TYPE SOMFY
move stop
CODE:
1 000002
READINGS:
2017-08-03 22:15:39 enc_key AB
2017-08-03 22:15:42 exact 0
2017-08-03 22:15:40 parsestate on
2017-08-03 22:15:42 position 0
2017-08-03 22:15:39 rolling_code 08BB
2017-08-03 22:15:42 state closed
Attributes:
IODev CUL_0
alias Rolladen Tür Wohnzimmer
devStateIcon .*oben:fts_shutter_20 .*unten:fts_shutter_90 .*Sonnenschutz:fts_shutter_60 .*100:fts_shutter_90
drive-down-time-to-100 20
drive-down-time-to-close 23
drive-up-time-to-100 3
drive-up-time-to-open 26
genericDeviceType blind
homebridgeMapping CurrentPosition=position,minValue=0,maxValue=100 TargetPosition=position,minStep=10,cmd=
icon fts_shutter_100
model somfyblinds
positionInverse 1
room Homekit,Somfy
userattr rollo_OG_Z2_tuer rollo_OG_Z2_tuer_map room_map structexclude
webCmd on:off
Zitat von: Joker2002
...
An den Somfy Rollläden habe ich seit Monaten nichts verändert, lediglich an meiner Rollladenautomatisierung gearbeitet. Sobald ich diese disable bleibt der Rollladen auch brav unten.
...
Und wie sieht diese Automatisierung aus. Und warum triggert da etw as alle 10 Minuten?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Zitat von: andies am 03 August 2017, 22:45:14
Meinst Du, dass ich die 325kHz mal erhöhe? Oder bringt das nix, weil das Problem, das Ralf9 erwähnt, damit nicht gelöst wird?
Gesendet von iPhone mit Tapatalk Pro
Naja ich würde die freq zu Testzwecken auf 433.420 setzen und mit den Fernbedienungsbuttons testen. Sofern das Problem beim Empfang besteht. Aber evtl. reicht auch eine höhere bwidth und eine andere Mittenfrequenz um Somfy und IT zu hören.
Hat dazu jemand Tests gemacht und kann Vorschläge machen?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Das kann ich mir auch nicht erklären. Laut FHEM ist die Automatik auf cmd6
Hier mal der Code
define DOIF_Rolladensteuerung_Tuer_Wohnzimmer DOIF
##############################
##-Rollladentür Wohnzimmer- ##
##############################
#########################
##Abwesenheitsschaltung##
#########################
## wenn der Anwesenheites Dummy auf "off" geschaltet ist sollen die Türen wieder runter fahren. 4:
(([Anwesend] eq "off") and ([rollo_wz_2_tuer:state] eq "open")) (set rollo_wz_2_tuer on)
DOELSEIF
## Von Mai bis August, wenn der Anwesenheits Dummy auf "on" schaltet, und die Temperatur von über 27 Grad erreicht ist, sollen die Rollläden an den Tür etwas hochfahren (Sonnenschutz), sofern der Rollladen im Bad geöffnet ist. 4:
(([Anwesend] eq "on") and (($month > 4) && ($month < 9)) and ([rollo_OG_Z6:state] eq "open") and ([rollo_wz_2_tuer:state] eq "closed") and ([TCM_Aussen:temperature] > 27) and ([Schlechtwetterdummy_Rollo] eq "off")) (set rollo_wz_2_tuer pos 71)
DOELSEIF
## wenn der Anwesenheits Dummy auf "on" schaltet, sollen die Rollläden an den Türen wieder hoch fahren, sofern der Rollladen im Bad geöffnet ist. 4:
(([Anwesend] eq "on") and ([rollo_OG_Z6:state] eq "open") and ([rollo_wz_2_tuer:state] eq "closed")) (set rollo_wz_2_tuer off)
DOELSEIF
#####################
##Sommerenschaltung##
#####################
## Von Mai bis August, wenn die Sonne hinten weg ist oder die Temperatur niedriger als 25 C ist oder die Wetterlage schlecht ist, soll die Rollladentür hochgefahren werden; wenn Anwesend 4:
((($month > 4) && ($month < 9)) and (([16:30]) or ([Schlechtwetterdummy_Rollo] eq "on") or ([TCM_Aussen:temperature] < 25)) and ([Anwesend] eq "on")) (set rollo_wz_2_tuer off)
DOELSEIF
## Von Mai bis August, wenn die Sonne hinten auf der Terasse angekommen ist und die Temperatur von über 27 Grad erreicht ist, soll der Rollladen etwas herunterfahren, wenn ANWESEND 4:
((($month > 4) && ($month < 9)) and ([07:05-16:29]) and ([TCM_Aussen:temperature] > 27) and ([Schlechtwetterdummy_Rollo] eq "off") and ([Fensterkontakt5] eq "closed") and ([Anwesend] eq "on")) (set rollo_wz_2_tuer pos 71)
DOELSEIF
##############################
##Rollladensteuerung täglich##
##############################
## Im Normalfall wird der Rollladen frühestens um 07.00 Uhr hochgefahren, wenn die Tür geschlossen ist; wenn ANWESEND 4:
(([{twilight("LichtWetter","sr","07:00","09:00")}]) and ([Anwesend] eq "on") and ([Fensterkontakt5] eq "closed")) (set rollo_wz_2_tuer off)
DOELSEIF
## im Normalfall fährt die Rollladentür nach Sonnenuntergang runter 4:
([([LichtWetter:ss]+[00:10])]) (set rollo_wz_2_tuer on)
DOELSEIF
## wenn die Tür geöffnet wird, soll der Rollladen hochfahren 0:0
(([rollo_wz_2_tuer] eq "closed") and ([Fensterkontakt5] eq "open")) (set rollo_wz_2_tuer off)
DOELSEIF
(([Rollladenstatus_dummy] eq "off") and (([rollo_wz_2_tuer] eq "open") and ([rollo_OG_Z6] eq "closed")) and ([Fensterkontakt5] eq "closed")) (set rollo_wz_2_tuer on)
wait 4:4:4:4:4:4:4:0:0
Hi,
Da ist doch ein Zielkonflikt drin:
Anwesend und Bad Rollo offen -> Türrollo öffnen
Temp hoch und Sommer und Anwesend -> Türrollo 71%
Wie häufig triggert Deine Anwesenheit?
Hast Du die Probleme auch, wenn das Badrollo zu ist?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Also das Rollo im Bad ist derzeit zu.
Die Anwesenheit on off wird über ein Dummy geschaltet der aber nur selten aktiviert wird, will sagen anwesend ist zu etwa 90 vom Tag aktiv.
Die restlichen im Haus haben eine fast gleichen Code und bleiben geschlossen. Nur die Tür im Wohnzimmer macht Probleme :(
Das Rollo im Bad macht keine Probleme
Lieber Joker2002,
Wenn Dein Badrollo auf ist UND Presence dann öffnen sich die Türrollos!
Meine Frage war, ob Du das Problem mit hoch/runter der Türrollos alle 10 Minuten auch hast, wenn das Badrollo zu ist?
Zweite Frage: Wie häufig wird die Anwesenheit festgestellt?
Edit: okay einen Post überlesen, Sorry.
Was sind denn die Unterschiede genau? Mit halben Infos ist das echt noch schwerer!
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Sorry das ich das nicht alles verstehe da ich noch FHEm Anfänger bin und lerne. Ich versuche daher die Fragen von dir zu beantworten:
Der Rollladen im Bad ist derzeit geschlossen während der Rollladen im Wohnzimmer ca. alle 10 Min hoch und wieder runter fährt.
Zu der Frage wie häufig die Anwesenheit festgestellt wird weiß ich nicht wie ich das in FHEM feststelle. Es ist ein Dummy Anwesend on/off den ich mitteils eines Schalters bediene.
Was mich halt nur Wunder ist, dass die anderen Türen mit dem gleichen DOIF nicht hoch und runter fahren.
Ich hoffe ich konnte Deine Fragen ausreichend beantworten :-\
Ja schon, aber dann bin ich auf dem Holzweg :-)
Wenn Presence manuell gesetzt wird, ist das keine Fehlerquelle. Wenn das Badrollo zu ist, ist das auch keine.
Kannst Du im rollo_wz_2_tuer (das fährt doch immer hoch runter, oder?) mal verbose auf 5 setzen und wenn es gefahren ist die relevanten Zeilen aus dem log posten?
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Hier der Auszug aus dem log:
2017.08.03 23:48:51 4: SOMFY_set: rollo_wz_2_tuer Inverse before cmd:off: arg1:: pos:0:
2017.08.03 23:48:51 4: SOMFY_set: rollo_wz_2_tuer Inverse after cmd:off: arg1:: pos:200:
2017.08.03 23:48:51 4: SOMFY_set: rollo_wz_2_tuer -> entering with mode :send: cmd :off: arg1 :: pos :200:
2017.08.03 23:48:51 4: SOMFY_set: handled command off --> move :off: newState :200:
2017.08.03 23:48:51 5: SOMFY_set: handled for drive/udpate: updateState :0: drivet :0: updatet :26:
2017.08.03 23:48:51 4: SOMFY_UpdateState: rollo_wz_2_tuer enter with newState:200: updatestate:0: move:off:
2017.08.03 23:48:51 4: SOMFY_UpdateState: rollo_wz_2_tuer after conversions newState:0: rounded:0: stateTrans:closed:
2017.08.03 23:48:51 4: SOMFY_sendCommand: rollo_wz_2_tuer -> cmd :off:
2017.08.03 23:48:51 5: SOMFY_sendCommand: rollo_wz_2_tuer -> message :sAB2008BB000002:
2017.08.03 23:48:51 4: SOMFY_set: rollo_wz_2_tuer -> update state in 26 sec
2017.08.03 23:48:52 4: SOMFY rollo_wz_2_tuer off
2017.08.03 23:48:54 4: SOMFY_TimedUpdate
2017.08.03 23:48:54 5: SOMFY_TimedUpdate : pos before convert so far : 0
2017.08.03 23:48:54 5: SOMFY_TimedUpdate : pos so far : 200
2017.08.03 23:48:54 5: SOMFY_TimedUpdate : delta time : 3.05 new rounde pos (rounded): 99.7826086956522
2017.08.03 23:48:54 4: SOMFY_UpdateState: rollo_wz_2_tuer enter with newState:99.7826086956522: updatestate:0: move:off:
2017.08.03 23:48:54 4: SOMFY_UpdateState: rollo_wz_2_tuer after conversions newState:10.195652173913: rounded:10: stateTrans:down:
2017.08.03 23:48:54 4: SOMFY_TimedUpdate: rollo_wz_2_tuer -> update state in 22.95 sec
2017.08.03 23:48:54 5: SOMFY_TimedUpdate: rollo_wz_2_tuer -> next time to stop: 1501796937.72007
2017.08.03 23:48:54 5: SOMFY_TimedUpdate DONE
2017.08.03 23:48:57 4: SOMFY_TimedUpdate
2017.08.03 23:48:57 5: SOMFY_TimedUpdate : pos before convert so far : 10.195652173913
2017.08.03 23:48:57 5: SOMFY_TimedUpdate : pos so far : 99.7826086956522
2017.08.03 23:48:57 5: SOMFY_TimedUpdate : delta time : 3.00 new rounde pos (rounded): 86.7391304347826
2017.08.03 23:48:57 4: SOMFY_UpdateState: rollo_wz_2_tuer enter with newState:86.7391304347826: updatestate:0: move:off:
2017.08.03 23:48:57 4: SOMFY_UpdateState: rollo_wz_2_tuer after conversions newState:21.9347826086957: rounded:20: stateTrans:20:
2017.08.03 23:48:57 4: SOMFY_TimedUpdate: rollo_wz_2_tuer -> update state in 19.95 sec
2017.08.03 23:48:57 5: SOMFY_TimedUpdate: rollo_wz_2_tuer -> next time to stop: 1501796940.71751
2017.08.03 23:48:57 5: SOMFY_TimedUpdate DONE
2017.08.03 23:49:00 4: SOMFY_TimedUpdate
2017.08.03 23:49:00 5: SOMFY_TimedUpdate : pos before convert so far : 21.9347826086957
2017.08.03 23:49:00 5: SOMFY_TimedUpdate : pos so far : 86.7391304347826
2017.08.03 23:49:00 5: SOMFY_TimedUpdate : delta time : 3.00 new rounde pos (rounded): 73.695652173913
2017.08.03 23:49:00 4: SOMFY_UpdateState: rollo_wz_2_tuer enter with newState:73.695652173913: updatestate:0: move:off:
2017.08.03 23:49:00 4: SOMFY_UpdateState: rollo_wz_2_tuer after conversions newState:33.6739130434783: rounded:30: stateTrans:30:
2017.08.03 23:49:00 4: SOMFY_TimedUpdate: rollo_wz_2_tuer -> update state in 16.95 sec
2017.08.03 23:49:00 5: SOMFY_TimedUpdate: rollo_wz_2_tuer -> next time to stop: 1501796943.71699
2017.08.03 23:49:00 5: SOMFY_TimedUpdate DONE
2017.08.03 23:49:03 4: SOMFY_TimedUpdate
2017.08.03 23:49:03 5: SOMFY_TimedUpdate : pos before convert so far : 33.6739130434783
2017.08.03 23:49:03 5: SOMFY_TimedUpdate : pos so far : 73.695652173913
2017.08.03 23:49:03 5: SOMFY_TimedUpdate : delta time : 3.00 new rounde pos (rounded): 60.6521739130435
2017.08.03 23:49:03 4: SOMFY_UpdateState: rollo_wz_2_tuer enter with newState:60.6521739130435: updatestate:0: move:off:
2017.08.03 23:49:03 4: SOMFY_UpdateState: rollo_wz_2_tuer after conversions newState:45.4130434782609: rounded:50: stateTrans:50:
2017.08.03 23:49:03 4: SOMFY_TimedUpdate: rollo_wz_2_tuer -> update state in 13.95 sec
2017.08.03 23:49:03 5: SOMFY_TimedUpdate: rollo_wz_2_tuer -> next time to stop: 1501796946.71405
2017.08.03 23:49:03 5: SOMFY_TimedUpdate DONE
2017.08.03 23:49:06 4: SOMFY_TimedUpdate
2017.08.03 23:49:06 5: SOMFY_TimedUpdate : pos before convert so far : 45.4130434782609
2017.08.03 23:49:06 5: SOMFY_TimedUpdate : pos so far : 60.6521739130435
2017.08.03 23:49:06 5: SOMFY_TimedUpdate : delta time : 3.00 new rounde pos (rounded): 47.6086956521739
2017.08.03 23:49:06 4: SOMFY_UpdateState: rollo_wz_2_tuer enter with newState:47.6086956521739: updatestate:0: move:off:
2017.08.03 23:49:06 4: SOMFY_UpdateState: rollo_wz_2_tuer after conversions newState:57.1521739130435: rounded:60: stateTrans:60:
2017.08.03 23:49:06 4: SOMFY_TimedUpdate: rollo_wz_2_tuer -> update state in 10.95 sec
2017.08.03 23:49:06 5: SOMFY_TimedUpdate: rollo_wz_2_tuer -> next time to stop: 1501796949.7146
2017.08.03 23:49:06 5: SOMFY_TimedUpdate DONE
2017.08.03 23:49:09 4: SOMFY_TimedUpdate
2017.08.03 23:49:09 5: SOMFY_TimedUpdate : pos before convert so far : 57.1521739130435
2017.08.03 23:49:09 5: SOMFY_TimedUpdate : pos so far : 47.6086956521739
2017.08.03 23:49:09 5: SOMFY_TimedUpdate : delta time : 3.00 new rounde pos (rounded): 34.5652173913044
2017.08.03 23:49:09 4: SOMFY_UpdateState: rollo_wz_2_tuer enter with newState:34.5652173913044: updatestate:0: move:off:
2017.08.03 23:49:09 4: SOMFY_UpdateState: rollo_wz_2_tuer after conversions newState:68.8913043478261: rounded:70: stateTrans:70:
2017.08.03 23:49:09 4: SOMFY_TimedUpdate: rollo_wz_2_tuer -> update state in 7.95 sec
2017.08.03 23:49:09 5: SOMFY_TimedUpdate: rollo_wz_2_tuer -> next time to stop: 1501796952.71444
2017.08.03 23:49:09 5: SOMFY_TimedUpdate DONE
2017.08.03 23:49:12 4: SOMFY_TimedUpdate
2017.08.03 23:49:12 5: SOMFY_TimedUpdate : pos before convert so far : 68.8913043478261
2017.08.03 23:49:12 5: SOMFY_TimedUpdate : pos so far : 34.5652173913044
2017.08.03 23:49:12 5: SOMFY_TimedUpdate : delta time : 3.00 new rounde pos (rounded): 21.5217391304348
2017.08.03 23:49:12 4: SOMFY_UpdateState: rollo_wz_2_tuer enter with newState:21.5217391304348: updatestate:0: move:off:
2017.08.03 23:49:12 4: SOMFY_UpdateState: rollo_wz_2_tuer after conversions newState:80.6304347826087: rounded:80: stateTrans:80:
2017.08.03 23:49:12 4: SOMFY_TimedUpdate: rollo_wz_2_tuer -> update state in 4.95 sec
2017.08.03 23:49:12 5: SOMFY_TimedUpdate: rollo_wz_2_tuer -> next time to stop: 1501796955.71732
2017.08.03 23:49:12 5: SOMFY_TimedUpdate DONE
2017.08.03 23:49:15 4: SOMFY_TimedUpdate
2017.08.03 23:49:15 5: SOMFY_TimedUpdate : pos before convert so far : 80.6304347826087
2017.08.03 23:49:15 5: SOMFY_TimedUpdate : pos so far : 21.5217391304348
2017.08.03 23:49:15 5: SOMFY_TimedUpdate : delta time : 3.00 new rounde pos (rounded): 8.47826086956523
2017.08.03 23:49:15 4: SOMFY_UpdateState: rollo_wz_2_tuer enter with newState:8.47826086956523: updatestate:0: move:off:
2017.08.03 23:49:15 4: SOMFY_UpdateState: rollo_wz_2_tuer after conversions newState:92.3695652173913: rounded:90: stateTrans:90:
2017.08.03 23:49:15 4: SOMFY_TimedUpdate: rollo_wz_2_tuer -> update state in 1.95 sec
2017.08.03 23:49:15 5: SOMFY_TimedUpdate: rollo_wz_2_tuer -> next time to stop: 1501796957.66735
2017.08.03 23:49:15 5: SOMFY_TimedUpdate DONE
2017.08.03 23:49:17 4: SOMFY_TimedUpdate
2017.08.03 23:49:17 5: SOMFY_TimedUpdate : pos before convert so far : 92.3695652173913
2017.08.03 23:49:17 5: SOMFY_TimedUpdate : pos so far : 8.47826086956523
2017.08.03 23:49:17 5: SOMFY_TimedUpdate : delta time : 1.95 new rounde pos (rounded): 8.88178419700125e-15
2017.08.03 23:49:17 4: SOMFY_UpdateState: rollo_wz_2_tuer enter with newState:0: updatestate:<undef>: move:stop:
2017.08.03 23:49:17 4: SOMFY_UpdateState: rollo_wz_2_tuer after conversions newState:100: rounded:100: stateTrans:open:
2017.08.03 23:49:17 4: SOMFY_set: rollo_wz_2_tuer Inverse before cmd:on: arg1:: pos:100:
2017.08.03 23:49:17 4: SOMFY_set: rollo_wz_2_tuer Inverse after cmd:on: arg1:: pos:0:
2017.08.03 23:49:17 4: SOMFY_set: rollo_wz_2_tuer -> entering with mode :send: cmd :on: arg1 :: pos :0:
2017.08.03 23:49:17 4: SOMFY_set: handled command on --> move :on: newState :0:
2017.08.03 23:49:17 5: SOMFY_set: handled for drive/udpate: updateState :200: drivet :0: updatet :23:
2017.08.03 23:49:17 4: SOMFY_UpdateState: rollo_wz_2_tuer enter with newState:0: updatestate:200: move:on:
2017.08.03 23:49:17 4: SOMFY_UpdateState: rollo_wz_2_tuer after conversions newState:100: rounded:100: stateTrans:open:
2017.08.03 23:49:17 4: SOMFY_sendCommand: rollo_wz_2_tuer -> cmd :on:
2017.08.03 23:49:17 5: SOMFY_sendCommand: rollo_wz_2_tuer -> message :sAC4008BC000002:
2017.08.03 23:49:17 4: SOMFY_set: rollo_wz_2_tuer -> update state in 23 sec
2017.08.03 23:49:17 5: SOMFY_TimedUpdate DONE
2017.08.03 23:49:18 4: SOMFY rollo_wz_2_tuer on
2017.08.03 23:49:20 4: SOMFY_TimedUpdate
2017.08.03 23:49:20 5: SOMFY_TimedUpdate : pos before convert so far : 100
2017.08.03 23:49:20 5: SOMFY_TimedUpdate : pos so far : 0
2017.08.03 23:49:20 5: SOMFY_TimedUpdate : delta time : 1501796960.70 new rounde pos (rounded): 50059898123.3333
2017.08.03 23:49:20 4: SOMFY_UpdateState: rollo_wz_2_tuer enter with newState:200: updatestate:<undef>: move:stop:
2017.08.03 23:49:20 4: SOMFY_UpdateState: rollo_wz_2_tuer after conversions newState:0: rounded:0: stateTrans:closed:
2017.08.03 23:49:20 5: SOMFY_TimedUpdate DONE
ich muss mich korrigieren, die anderen Türen fahren auch hoch und runter :(
Zitat von: Joker2002 am 03 August 2017, 22:59:01
Das kann ich mir auch nicht erklären. Laut FHEM ist die Automatik auf cmd6
Hier mal der Code
define DOIF_Rolladensteuerung_Tuer_Wohnzimmer DOIF
##############################
##-Rollladentür Wohnzimmer- ##
##############################
#########################
##Abwesenheitsschaltung##
#########################
## wenn der Anwesenheites Dummy auf "off" geschaltet ist sollen die Türen wieder runter fahren. 4:
(([Anwesend] eq "off") and ([rollo_wz_2_tuer:state] eq "open")) (set rollo_wz_2_tuer on)
DOELSEIF
## Von Mai bis August, wenn der Anwesenheits Dummy auf "on" schaltet, und die Temperatur von über 27 Grad erreicht ist, sollen die Rollläden an den Tür etwas hochfahren (Sonnenschutz), sofern der Rollladen im Bad geöffnet ist. 4:
(([Anwesend] eq "on") and (($month > 4) && ($month < 9)) and ([rollo_OG_Z6:state] eq "open") and ([rollo_wz_2_tuer:state] eq "closed") and ([TCM_Aussen:temperature] > 27) and ([Schlechtwetterdummy_Rollo] eq "off")) (set rollo_wz_2_tuer pos 71)
DOELSEIF
## wenn der Anwesenheits Dummy auf "on" schaltet, sollen die Rollläden an den Türen wieder hoch fahren, sofern der Rollladen im Bad geöffnet ist. 4:
(([Anwesend] eq "on") and ([rollo_OG_Z6:state] eq "open") and ([rollo_wz_2_tuer:state] eq "closed")) (set rollo_wz_2_tuer off)
DOELSEIF
#####################
##Sommerenschaltung##
#####################
## Von Mai bis August, wenn die Sonne hinten weg ist oder die Temperatur niedriger als 25 C ist oder die Wetterlage schlecht ist, soll die Rollladentür hochgefahren werden; wenn Anwesend 4:
((($month > 4) && ($month < 9)) and (([16:30]) or ([Schlechtwetterdummy_Rollo] eq "on") or ([TCM_Aussen:temperature] < 25)) and ([Anwesend] eq "on")) (set rollo_wz_2_tuer off)
DOELSEIF
## Von Mai bis August, wenn die Sonne hinten auf der Terasse angekommen ist und die Temperatur von über 27 Grad erreicht ist, soll der Rollladen etwas herunterfahren, wenn ANWESEND 4:
((($month > 4) && ($month < 9)) and ([07:05-16:29]) and ([TCM_Aussen:temperature] > 27) and ([Schlechtwetterdummy_Rollo] eq "off") and ([Fensterkontakt5] eq "closed") and ([Anwesend] eq "on")) (set rollo_wz_2_tuer pos 71)
DOELSEIF
##############################
##Rollladensteuerung täglich##
##############################
## Im Normalfall wird der Rollladen frühestens um 07.00 Uhr hochgefahren, wenn die Tür geschlossen ist; wenn ANWESEND 4:
(([{twilight("LichtWetter","sr","07:00","09:00")}]) and ([Anwesend] eq "on") and ([Fensterkontakt5] eq "closed")) (set rollo_wz_2_tuer off)
DOELSEIF
## im Normalfall fährt die Rollladentür nach Sonnenuntergang runter 4:
([([LichtWetter:ss]+[00:10])]) (set rollo_wz_2_tuer on)
DOELSEIF
## wenn die Tür geöffnet wird, soll der Rollladen hochfahren 0:0
(([rollo_wz_2_tuer] eq "closed") and ([Fensterkontakt5] eq "open")) (set rollo_wz_2_tuer off)
DOELSEIF
(([Rollladenstatus_dummy] eq "off") and (([rollo_wz_2_tuer] eq "open") and ([rollo_OG_Z6] eq "closed")) and ([Fensterkontakt5] eq "closed")) (set rollo_wz_2_tuer on)
wait 4:4:4:4:4:4:4:0:0
Ich denke, das doelseif mit den 27 Grad und das doelseif von 7 bis 9 wechseln sich lustig ab. Getriggert wird das vielleicht von twilight.
Grüße Stefan.
Das war ja auch mein Gedanke, aber 71 ist nur ein bisschen auf und nicht komplett. Im Log sehe ich aber 100, 200 und 0. also zwischen on und off gibt es irgendwo ein Wechselspiel.
Kannst Du in Deinen Doifs keine Logausgabe einbauen, damit Du weisst, welches triggert?
Oder aber stacktrace nutzen.
Siehe https://forum.fhem.de/index.php/topic,58237.msg496560.html#msg496560
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Ich werde mal schauen was sich da machen lässt.
Das Attribut "global" ist jedoch in dem DOIF der Automatik nicht vorhanden?
Was mich eben nur wundert ist, dass es vorgestern noch ohne Probleme ging. Das einzige was ich am DOIF verändert habe war der Bausteinblock mit der Abwesenheitsschaltung.
In FHEM sehe ich, dass zwischen den einzelenen Positionen innerhalb der Automatik nicht geschaltet wird (steht immer fest auf cmd 6) während die Rollläden hoch- und runterfahren.
global ist nicht in einem device sondern eben global findest Du im Raum Everything unter global ;-)
Vielleicht schauen wir an der falschen Stelle, wir werden es sehen...
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Ok, danke für die Erleuchtung :)
das Attribut ist gesetzt. Folgende Zeilen spuckt FHEM dann im Log aus:
2017.08.04 07:25:11 1: stacktrace:
2017.08.04 07:25:11 1: main::__ANON__ called by (eval 8044) (1)
2017.08.04 07:25:11 1: (eval) called by ./FHEM/33_readingsGroup.pm (355)
2017.08.04 07:25:11 1: main::lookup2 called by ./FHEM/33_readingsGroup.pm (538)
2017.08.04 07:25:11 1: main::readingsGroup_value2html called by ./FHEM/33_readingsGroup.pm (1107)
2017.08.04 07:25:11 1: main::readingsGroup_2html called by ./FHEM/33_readingsGroup.pm (1207)
2017.08.04 07:25:11 1: main::readingsGroup_detailFn called by ./FHEM/01_FHEMWEB.pm (1853)
2017.08.04 07:25:11 1: main::FW_showRoom called by ./FHEM/01_FHEMWEB.pm (1061)
2017.08.04 07:25:11 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (548)
2017.08.04 07:25:11 1: main::FW_Read called by fhem.pl (3423)
2017.08.04 07:25:11 1: main::CallFn called by fhem.pl (689)
2017.08.04 07:25:11 1: PERL WARNING: Argument "100 %" isn't numeric in numeric lt (<) at (eval 8045) line 1.
2017.08.04 07:25:11 1: stacktrace:
2017.08.04 07:25:11 1: main::__ANON__ called by (eval 8045) (1)
2017.08.04 07:25:11 1: (eval) called by ./FHEM/33_readingsGroup.pm (355)
2017.08.04 07:25:11 1: main::lookup2 called by ./FHEM/33_readingsGroup.pm (538)
2017.08.04 07:25:11 1: main::readingsGroup_value2html called by ./FHEM/33_readingsGroup.pm (1107)
2017.08.04 07:25:11 1: main::readingsGroup_2html called by ./FHEM/33_readingsGroup.pm (1207)
2017.08.04 07:25:11 1: main::readingsGroup_detailFn called by ./FHEM/01_FHEMWEB.pm (1853)
2017.08.04 07:25:11 1: main::FW_showRoom called by ./FHEM/01_FHEMWEB.pm (1061)
2017.08.04 07:25:11 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (548)
2017.08.04 07:25:11 1: main::FW_Read called by fhem.pl (3423)
2017.08.04 07:25:11 1: main::CallFn called by fhem.pl (689)
2017.08.04 07:25:11 1: PERL WARNING: Argument "80 %" isn't numeric in numeric lt (<) at (eval 8052) line 1.
2017.08.04 07:25:11 1: stacktrace:
2017.08.04 07:25:11 1: main::__ANON__ called by (eval 8052) (1)
2017.08.04 07:25:11 1: (eval) called by ./FHEM/33_readingsGroup.pm (355)
2017.08.04 07:25:11 1: main::lookup2 called by ./FHEM/33_readingsGroup.pm (538)
2017.08.04 07:25:11 1: main::readingsGroup_value2html called by ./FHEM/33_readingsGroup.pm (1107)
2017.08.04 07:25:11 1: main::readingsGroup_2html called by ./FHEM/33_readingsGroup.pm (1207)
2017.08.04 07:25:11 1: main::readingsGroup_detailFn called by ./FHEM/01_FHEMWEB.pm (1853)
2017.08.04 07:25:11 1: main::FW_showRoom called by ./FHEM/01_FHEMWEB.pm (1061)
2017.08.04 07:25:11 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (548)
2017.08.04 07:25:11 1: main::FW_Read called by fhem.pl (3423)
2017.08.04 07:25:11 1: main::CallFn called by fhem.pl (689)
2017.08.04 07:25:11 1: PERL WARNING: Argument "100 %" isn't numeric in numeric lt (<) at (eval 8053) line 1.
2017.08.04 07:25:11 1: stacktrace:
2017.08.04 07:25:11 1: main::__ANON__ called by (eval 8053) (1)
2017.08.04 07:25:11 1: (eval) called by ./FHEM/33_readingsGroup.pm (355)
2017.08.04 07:25:11 1: main::lookup2 called by ./FHEM/33_readingsGroup.pm (538)
2017.08.04 07:25:11 1: main::readingsGroup_value2html called by ./FHEM/33_readingsGroup.pm (1107)
2017.08.04 07:25:11 1: main::readingsGroup_2html called by ./FHEM/33_readingsGroup.pm (1207)
2017.08.04 07:25:11 1: main::readingsGroup_detailFn called by ./FHEM/01_FHEMWEB.pm (1853)
2017.08.04 07:25:11 1: main::FW_showRoom called by ./FHEM/01_FHEMWEB.pm (1061)
2017.08.04 07:25:11 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (548)
2017.08.04 07:25:11 1: main::FW_Read called by fhem.pl (3423)
2017.08.04 07:25:11 1: main::CallFn called by fhem.pl (689)
Ist es richtig das die Somfy Rolling_codes in /opt/Fhem/log/fhem.save gespreichert werden ?
Ich ziehe gerade um und das macht mir noch Probleme.
@GeZi3560: Ja wie alle Readings werden diese in fhem.save gespeichert, normalerweise unter dem von Dir angegebenen Pfad.
Ich habe gerad auch ein Problem, wahrscheinlich mit den Rolling Code. Nach einem Update und Shutdown Restart funktionieren nur noch ein Teil der Rollläden.
Wenn es bis jetzt der Fall war habe ich einfach ein paar mal auf go-my gedrückt bis der Rolling Code wieder mit dem vom Rollladen erwarteten übereinstimmte. Dann lief es wieder.
Heute Morgen habe ich bei einem Rolladen schon 150 mal den go-my Befehl gesendet und nichts rührt sich.
Gibt es da mittlerweile eine andere Möglichkeit die Rolling Codes anzupassen. Oder kann man den Rolling Code aus der fhem.save rekonstruieren?
Nachtrag:
Wenn ich den enc_key und rolling_code aus der fhem.save von vor zwei Tagen beim zugehörigen Rolladen über das Attribut eintrage sollte es doch nach wenigen Befehlen wieder Synchron sein und die Rollläden sollten sich wieder bewegen. Pro Tag fahren die Rolläden nur 6 mal. Berichtigt mich falls ich es falsch verstanden habe.
@majorshark: Die Vermutung aus Deinem Nachtrag ist eigentlich soweit korrekt, wenn die fhem.save einigermassen aktuell ist. Ich vermute Du hast auch geprüft, dass die rollingcodes aus den Attributen in die Readings übernommen wurden?
Danke für die Info.
Die fhem.save ist vom 23.08. Ist als nicht sooo alt. Das die Rollingcodes aus den Attributen übernommen werden sehe ich mir an wenn ich wieder vor den Rollos stehe.
Edit:
Es liegt nicht an den Rollingcodes oder fhem.save oder dem Modul. Mein sduinoCC1101 tut es nur noch bedingt. Heute Morgen gingen noch die Rollläden die nah mein sduino sind. Jetzt geht nur noch die Dooya Markise. IT schalten geht auch nicht mehr.
Ich geh mal auf die Fehlersuche.
Hallo zusammen,
vielleicht kann mit jemand helfen..
Ich habe seit 2 Jahren 11 Somfy rts Rollläden in Betrieb an einem RPI2 mit CUL auf 886 Mhz Basis im rfmode Homeatic.
Seit ein paar Tagen kann ich einen Rollo über FHEM nicht mehr steuern. Per angelernter FB überhaupt kein Problem.
Nach reichlicher Analyse und Neuanlage des Rollos weiter kein Erfolg.
Was bisher gemeacht wurde:
Neuanlage in FHEM mit anderem selben Code, Rolling-Code und encKey --> kein Erfolg
Neuanlage in FHEM mit anderem Code und neuem Rolling-Code und encKey --> kein Erfolg
Komplettes Rücksetzen des RTS in Auslieferungszustand nebst Neueinstellung der Endlagen und anleren einer FB --> kein Erfolg
Anbei ein Log beim betätigen in FHEM:
2017.10.01 11:56:32 4: SOMFY_set: Bad -> entering with mode :send: cmd :off: arg1 :: pos :26:
2017.10.01 11:56:32 4: SOMFY_set: handled command off --> move :off: newState :26:
2017.10.01 11:56:32 5: SOMFY_set: handled for drive/udpate: updateState :0: drivet :0: updatet :4.94:
2017.10.01 11:56:32 4: SOMFY_UpdateState: Bad enter with newState:26: updatestate:0: move:off:
2017.10.01 11:56:32 4: SOMFY_UpdateState: Bad after conversions newState:26: rounded:30: stateTrans:30:
2017.10.01 11:56:32 4: SOMFY_sendCommand: Bad -> cmd :off:
2017.10.01 11:56:32 5: SOMFY_sendCommand: Bad -> message :sA820000A000044:
2017.10.01 11:56:32 4: SOMFY_set: Bad -> update state in 4.94 sec
Sieht eigentlich sehr gut aus und ähnelt den anderen 10 Rollos.
Jetzt kommt das unheimliche:
Ich habe zum Test (um Defekte am RTS auszuschliessen) den CUL-Stick neu an meinen zweiten RPI angeschlossen.
Dort den Rollo dann ebenfalls mal angelegt (vorher noch mal komplett zurückgesetzt!) und mit Hilfe der ersten FB den Rollo auch hier in den Anlernmodus gebracht.
Dann im FHEM vom zweiten RPi set Bad prog geklickt und siehe da --> das Rollo bewegt sich ??? ??? ???
Dann alles wieder umgebaut und das gleiche define von Bad im ersten FHEM gesetzt inkl. Rolling-Code und EncKey. --> wieder kein Erfolg
Wie kann das sein?
Bevor ich jetzt für den einen Rollo mir einen zweiten CUL besorge hat vielleicht jemand noch einen zündende Idee?
Danke und Grüße,
Dirk
Es könnte sein, dass ein 433 Mhz Sender mit schwacher Batterie stört, das war bei mir der Fall, als ein Rolladen nur spontan angesteuert werden konnte.
*hm wie könnte man das ausschliessen mit dem Sender?
Das prog Kommando ist ja etwas speziell da man nur einlernen kann wenn eine FB den Rollo in den Vorgang gebracht hat.
Es macht auch keinen Unterschied welche FB (vier verschiedene) ich nutze. Jegliche weitere FB vom somfy geht problemlos. Somit sind nach dem Reset eh wieder 12 Plätze im Empfänger frei.
Beim zweiten Pi klappts ja auf anhieb mit dem prog Befehl.
Generell klingt es für mich nach einem möglichen Reichweitenproblem mit Deinem 868Mhz Cul, da alles was Du ausprobiert hast ja viele andere Dinge ausschliesst. Leider verändert sich die Recihweite auch gerne mal durch äussere Einflüsse, etwas auf dem Weg zwischen CUL und Empfänger, Reflektionen, ... Ausserdem ist ein 868Mhz Cul ist eben auf 433 Mhz nicht sehr gut abgestimmt.
Zitat von: Devender am 01 Oktober 2017, 14:49:40
*hm wie könnte man das ausschliessen mit dem Sender?
Batterien aus dem Sender nehmen oder wechseln.
Hi,
heute früh noch mal ein wenig probiert und in der Tat war der Hinweis mit Empfangsproblemen der richtige.
Ich habe zum Test den RPi nebst CUL ins Bad gestellt und dort ging der prog Befehl sofort.
Mich wundert nur, dass der Badrollo nicht der ist, der am weitesten weg ist. Der Rpi steht eigentlich fast Mittig im Haus.
Nach Rückbau an seine alte Position geht auch ein normaler "set Rollo off" wieder wie erwartet.
Ich werde das mal beobachten - Danke! :)
Grüsse,
Dirk
Hi,
ich muss hier jetzt nochmal ganz doof fragen.
Habe meine SOMFY Rolläden über FHEM laufen.
Vom FHEM sende ich Befehle über meinen MapleCUL, das geht super im ganzen Haus.
Empfangen tue ich auch die Hand/Wandsender über FHEMduino und über rawDevice gebe ich die empfangenen Komandos an den jeweilige FHEM Rolladen weiter.
D.h. z.b. mein Rolladen Dev 0000001 (eingelerneter FHEM sender) wird auch mit Stati vom Hand/Wandsender 96216C versorgt.
So sehe ich auch den Status des Rolladen wenn jemand nicht über FHEM sondern Hand/Wandsender den Rolladen fährt.
Beim Fhemduino habe ich aber das Problem dass es nicht alle Sender sauber empfängt.
Mittlerweile empfängt ja auch der Sduino und den würde ich auch gern die stati der Hand/Wandsender an mein FHEM Rolladen device weiter geben lassen, finde aber nichts entsprechendes.
Ist soetwas vorgesehen?
Gruß,
Stefan
@stefanru: Generell ist das schon geplant, allerdings habe ich bei mir nachwievor keine stabile Empfangssituation mit dem Signalduino bei Somfy, es werden weit weniger als die Hälfte der Befehle richtig erkannt. Damit ist das heute für mich immer noch nicht umsetzbar.
Kann das an der Somfy-Frequenz liegen, die ist ja nicht 433,92MHz?
Hi,
OT: Hat hier jemand erfolgreich einen Mischbetrieb zwischen 433.420 (Somfy) und 433.920 (SlowRF z.B. Intertechno) MHz laufen?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Zitat von: andies am 20 November 2017, 06:34:27
Kann das an der Somfy-Frequenz liegen, die ist ja nicht 433,92MHz?
Nein: Die habe ich im Signalduino (bei der CC1101-Version) angepasst, das hat Verbesserungen in der Recihweite gebracht, aber noch nicht eine saubere Erkennung. Da gibt es wohl auch Probleme dadurch, dass das Somfy-Protokoll keine "Einschwingphase" enthält, die ein sauberes Erkennen des ersten Bits erlaubt.
Zitat von: RaspiLED am 20 November 2017, 14:15:18
Hi,
OT: Hat hier jemand erfolgreich einen Mischbetrieb zwischen 433.420 (Somfy) und 433.920 (SlowRF z.B. Intertechno) MHz laufen?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Leider immer noch nicht: https://forum.fhem.de/index.php/topic,72886
Leider ist der SignalDuino auch relativ weit vom Somfy Handsender entfernt. Wenn ich das Setup geändert habe, teste ich weiter.
Zitat von: RaspiLED am 20 November 2017, 14:15:18
Hi,
OT: Hat hier jemand erfolgreich einen Mischbetrieb zwischen 433.420 (Somfy) und 433.920 (SlowRF z.B. Intertechno) MHz laufen?
Ja, allerdings Brennenstuhl statt Intertechno (leicht anders) und ich empfange Somfy nicht (jedenfalls nur manchmal), ich sende nur.
Zitat von: RaspiLED am 20 November 2017, 14:15:18
Hi,
OT: Hat hier jemand erfolgreich einen Mischbetrieb zwischen 433.420 (Somfy) und 433.920 (SlowRF z.B. Intertechno) MHz laufen?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Was meinst du genau damit?
Ich sende mit meinem MapleCul und einem Stamp 433Mhz cc1101. Das geht bei mir einwandfrei. Alle Somfy und auch alle Steckdosen.
Empfangen wie gesagt mache ich zur Zeit mit dem FHEMduino. Aber da habe ich die gleichen Probleme die du beschreibst.
Reichweite zum Empfangen ist nicht gerade so gut und richtig erkannt wird es nur wenn ich den Somfy Handsender länger drucke als nötig.
Könnte man testweise so eine rawdevice Einstellung wie beim FHEMduino einbauen?
Ich habe das Gefühl das mein Signalduino besser empfängt. Würde das dann mal testen.
Gruß,
Stefan
hallo,
gibt es bereits besserer lösungen als die im wiki beschriebenen um die rolling codes in eine neue fhem version zu übernehmen?
reicht es die /fhem/log/fhem.save einfach zu kopieren?
Zitat von: RaspiLED am 20 November 2017, 14:15:18
Hi,
OT: Hat hier jemand erfolgreich einen Mischbetrieb zwischen 433.420 (Somfy) und 433.920 (SlowRF z.B. Intertechno) MHz laufen?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
ja, hier.
Hi,
Der Rolling Code ist dich im internal gespeichert und nicht in der config, oder? Demnach müsste bei der Definition im neuen fhem schon der richtige Rollingcode ünergeben werden oder das internal gesetzt werden. Geht das mit FHEM Bordmitteln?
Parallelbetrieb: welche ccconf Daten nutzt Du?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Zitat von: RaspiLED am 29 November 2017, 15:14:39
...
Parallelbetrieb: welche ccconf Daten nutzt Du?
Gruß Arnd
nanoCUL ccconf => freq:433.000MHz bWidth:464KHz rAmpl:42dB sens:4dB
VERSION V 1.65 nanoCUL433
ich habe die definitionen so:
define ELRO_00000_B IT FFFFFF0FFF FF F0
attr ELRO_00000_B IODev nanoCUL
attr ELRO_00000_B ITfrequency 433.000
attr ELRO_00000_B ITrepetition 12
attr ELRO_00000_B alias WZ-Fenster
attr ELRO_00000_B group Schalter
attr ELRO_00000_B model itswitch
attr ELRO_00000_B room Haus,Wohnzimmer
define KZN2 SOMFY 000014
attr KZN2 IODev nanoCUL
attr KZN2 alias Emma Nord
attr KZN2 devStateIcon Öffnen:fts_shutter_down Schließen:fts_shutter_up stop:fts_shutter_updown
attr KZN2 eventMap /go-my:MY/ /on:Schließen/ /off:Öffnen
attr KZN2 group Rolladen
attr KZN2 repetition 3
attr KZN2 room Emma,Haus
attr KZN2 webCmd MY:Schließen:Öffnen
ich weiß das ich am anfang probleme hatte mit dem system. immer wenn eine steckdose geschaltet wurde gingen die rolläden nicht. allerdings ist das 3 jahre her. das ich aber grade einen raspi neu aufbaue kann sien das ich wieder das problem habe. die elros sind eh scheiße. da kommen dann schalter mit rückmeldung rein.
Zitat von: RaspiLED am 29 November 2017, 15:14:39
Hi,
Der Rolling Code ist dich im internal gespeichert und nicht in der config, oder? Demnach müsste bei der Definition im neuen fhem schon der richtige Rollingcode ünergeben werden oder das internal gesetzt werden. Geht das mit FHEM Bordmitteln?
...
du keine ahnung. ich will einfach umziehen auf einen anderen raspi. das system läuft schon 3 jahre und demensprechend weit sind die codes. das dauert ja tage.
ich könnte alles entlernen und neu anlernen aber das will ich vermeiden weil ich auch ein brauchbares backup regelmäßig ziehn will.
//edit
komplettes backup ziehen und neu einspielen geht ohne probleme
Zitat von: realkeule am 29 November 2017, 21:38:21
nanoCUL ccconf => freq:433.000MHz bWidth:464KHz rAmpl:42dB sens:4dB
attr ELRO_00000_B ITFREQUENCY 433.000
komplettes backup ziehen und neu einspielen geht ohne probleme
433.000 ļst aber ungewöhnlich. Normalerweisebist IT auf 433.920 und Somfy auf 433.420.
Hörst Du denn auch die ELRO Fernbedienung?
Gruß Arnd
Gesendet von meinem SM-G800F mit Tapatalk
Hallo,
hier ist für die nanoCul Hardware eine Signalduino Testversion mit überarbeitetem Manncester Decoder:
https://forum.fhem.de/index.php/topic,58396.msg733723.html#msg733723
Bitte mal testen ob sich damit die Erkennung der Fernbedienung deutlich verbessert.
Log Ausgaben in dieser Form sind dabei hilfreich:
DMC;P0=2499;P1=-2621;P2=5052;P3=-1309;P4=1258;P5=626;P6=-659;D=0101010101010123_4343565643565646534653565646534656565356435646565653564653434356565656465656565656565;
MC;LL=-1309;LH=1258;SL=-659;SH=626;D=AEE4E436195F00;C=641;L=56;s16;b16;s12l_LlLlSsSsLlSsSsLsSlLsSlSsSsLsSl
Gruß Ralf
Hallo Ralf,
Zitat:
hier ist für die nanoCul Hardware eine Signalduino Testversion mit überarbeitetem Manncester Decoder:
Hat sich da beim SinganlDuino auch etwas getan?
Ich empfange zwar die Signale von den Handsendern, aber als Somfy-Device werden die Codes nur mit ca. 50 % erkannt, was etwas schade ist....
Wir hatten ja vor einigen Monaten da schon mal etwas herum experimentiert, aber keine wirkliche Verbesserung erzielt.
Elektrolurch
Hallo Elektrolurch,
Es müsste sich damit bei allen Signalduino Hardware Varianten eine deutliche Verbesserung ergeben.
Welche Signalduino Hardware hast Du?
Gruß Ralf
Zitat von: RaspiLED am 30 November 2017, 20:33:59
433.000 ļst aber ungewöhnlich. Normalerweisebist IT auf 433.920 und Somfy auf 433.420.
Hörst Du denn auch die ELRO Fernbedienung?
Gruß Arnd
Gesendet von meinem SM-G800F mit Tapatalk
sorry für die verspätung.
ich höre nicht auf die fb.
die IT´s habe ich mal von der frequenz angepasst.
wie ändere ich denn die cul frequenz? alles schon so lange her. oder ist das richtig in cconf?
die somfy rolladen reagieren nicht immer seit dem ich eine ccu in der nähe habe was vllt an der ungenauen frequenz liegt.
set cul freq 433.420
bzw.
set SDuino cc1101_freq 433.420
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Hallo zusammen,
bekomme seit Update gestern diese Einträge im Log.
hab ich was verpasst ?
2018.01.05 07:30:00 1: DEBUG>SOMFY Parse: RolloWG msg: YsA9260A79210000 --> 20-off
2018.01.05 07:30:01 1: DEBUG>SOMFY Parse: RolloWZ1 msg: YsA3230A03100000 --> 20-off
2018.01.05 07:30:02 1: DEBUG>SOMFY Parse: RolloWZ2 msg: YsA72B0CD7200000 --> 20-off
2018.01.05 07:30:03 1: DEBUG>SOMFY Parse: RolloMR msg: YsAB28066B220000 --> 20-off
2018.01.05 07:30:04 1: DEBUG>SOMFY Parse: RolloWZ2 msg: YsA82B0CD8200000 --> 20-off
2018.01.05 07:30:05 1: DEBUG>SOMFY Parse: RolloUG1 msg: YsAA2505AA310000 --> 20-off
2018.01.05 07:30:06 1: DEBUG>SOMFY Parse: RolloUG2 msg: YsAF2E052F320000 --> 20-off
Thanks Gerd
Ja, denn die Ankündigung ist im offiziellen SOMFY-Thread im passenden Forum passiert:
https://forum.fhem.de/index.php/topic,53319.msg736931.html#msg736931 (https://forum.fhem.de/index.php/topic,53319.msg736931.html#msg736931)
Bitte diesen Thread nicht weiter für Unterstützung zu 10_SOMFY benutzen sondern den Link / Thread oben verwenden
Danke