Test Adapter EnOcean (2) v0.3.x
-
Hallo - ich mach noch mal die Baustelle FWS61 auf. Habe mir die Sensortelegramme nochmal angeschaut und festgestellt, daß Telegrammteil 1 falsch ausgewertet wird. Hier mein Beispiel an dem ich das nachvollzogen habe:
enocean.0 2021-01-29 11:50:03.074 debug (265027) Message for ID 058dda99 has been received. enocean.0 2021-01-29 11:50:03.071 debug (265027) 55000a0701eba5ff7d001a058dda990000ffffffff3d00 enocean.0 2021-01-29 11:49:43.705 debug (265027) Message for ID 058dda99 has been received. enocean.0 2021-01-29 11:49:43.703 debug (265027) 55000a0701eba500030128058dda990000ffffffff3d00so werden die Werte im Objekt ausgegeben:
CMD state Command ID state state Teach-in(0) DWS state Dawn sensor state value.brightness 251.0824 lx RAN state Rain state switch false SNE state Sun East state value.brightness 0.5882 klx SNS state Sun South state value.brightness 1.7645999999999997 klx SNW state Sun West state value.brightness 0 klx TMP state Temperature state value.temperature 18.83 °C WND state Wind speed state value.battery 70.00 V rssi state Signal Strength state value.rssi -61 dBmdas ist meine Umrechnung laut der Eltako Sensor-Telegramm-Tabelle für den FWS61:
Telegrammteil 1 Wert ist(eig.Berechn.) Ausgabe in iobroker ff 255(=1000lx) 251,08 7d 125(=18,82°C) 18,83 00 0 70,00 1a true(=Regen) false Telegrammteil 2 00 0 0 03 3(1,7647klx) 1,7646 01 1(0,5882klx) 0,5882 28 statischDabei ist die Ausgabe für Dämmerungswert, Windgeschwindigkeit und Regen falsch, bei den anderen sind es ja teilweise nur im hinteren Kommabereich Rundungsabweichungen, welche nicht relevant sind.
Ich habe den FWS61 jetzt mit der Konfig aus Version 0.3.1 in der Version 0.3.0 manuell angelegt - die Werte sind gleich.
-
@jey-cee
gute Neuigkeiten: Habe nochmal die Version 0.3.1 installiert (hat mir einfach keine Ruhe gelassen, zumal Du ja auch keinen Fehler finden konntest).
Vorgehensweise von mir war diesmal jedoch etwas anders:- alle Objekte gelöscht
- Version 0.3.0 deinstalliert
- ioBroker gestoppt (neu)
- ioBroker gestartet (neu)
- Version 0.3.1 installiert
- Instanz erzeugt und neue Geräte eingelernt
Beispiel (Raw) eines Aktors:
{ "type": "device", "common": { "name": "Blind actuator" }, "native": { "id": "0584ab89", "eep": [ "TF-01-01", "F6-02-02" ], "manufacturer": "ELTAKO", "Sender_ID": "ffea0e03", "baseIDoffset": 3 }, "from": "system.adapter.enocean.0", "user": "system.user.admin", "ts": 1612017314872, "_id": "enocean.0.0584ab89", "acl": { "object": 1636, "owner": "system.user.admin", "ownerGroup": "system.group.administrator" } }Bin jetzt beim dritten Aktor - und es funktioniert. Für meine Installation wäre jetzt momentan nur noch das Fehlerbild des FWS61 offen.
Also ioBroker stoppen/starten hat vielleicht die entscheidende Änderung des Verhaltens bewirkt. Eventuell war doch noch was im Hintergrund, daß sich bei der Software was unplausibel verhalten hat... -
@mustang Jetzt warst du etwas zu schnell, ich hab gerade noch den FWS61 gefixt.
-
@jhpaulsen Am besten du testest es vorher mit einem und entscheidest dann selsbt.
-
@jey-cee
Top - habe eben noch ein Update der Version 0.3.1 gemacht - der FWS61 sieht jetzt auch gut aus.
Vielen Dank und demnächst läuft bei Dir auch noch mal eine Spende ein...
Ist es schon absehbar wann es eine finale Version geben wird, wo ich dann vielleicht ein vorerst letztes mal eine komplette Neuinstallation machen müßte? -
@mustang schwer ab zu schätzen, letztlich hängt das davon ab ob noch jemand Gravierende Fehler findet.
Aktuell würde ich sagen in 3 Monaten kann man darüber Nachdenken.Bei den Geräten könnte es auch noch Änderungen geben, in der Form das die Befehle vereinfacht werden oder Objekte dazu/weg kommen. Das kann ich aber nur mit entsprechendem Feedback machen, weil ich selber die Geräte ja nicht in Benutzung hab. Dadurch sehe ich nicht an welcher stelle man optimieren kann.
-
Ich hab mal mit den Dimmern FUD61NPN noch etwas getestet. Das Objekt Dimming Speed ist im RAW fest auf 0 eingestellt (use Hardware setting). Wenn ich den vordefinierten Wert in den Objekteinstellungen raus nehme kann ich die Dimmgeschwindigkeit ändern. Man kann hier Angaben von 0 bis 255 machen. Vielleicht kann man das in einer nächsten Version einpflegen.
Bin auch noch am Überlegen wann ich den Adapter ins Livesystem übernehme. -
@mane444 sagte in Test Adapter EnOcean (2) v0.3.x:
Das Objekt Dimming Speed ist im RAW fest auf 0 eingestellt (use Hardware setting).
Nein ist es nicht. Du kannst auch jeden anderen Wert rein schreiben, stift symbol.
Die vordefinierten States sind nur eine Hilfe damit man die Möglichkeiten sehen kann. Nur eine Range lässt sich nicht abbilden. -
@jey-cee
Ups klar, ich hab's immer direkt im Feld probiert. -
@jey-cee nach mehrfachem Löschen und Installieren, scheint der Adapter soweit zu funzten (hatte mehrfach Probleme, dass er die baseid nicht richtig gesetzt hat)
Bis auf den fud14 funktionieren alle Geräte die ich betreibe. Den Fud14 kann ich nicht steuern, im Log erscheint beim Versuch auf zufahren:
enocean.0 2021-02-01 11:51:24.205 debug (14257) Packet type 2 received: 02 enocean.0 2021-02-01 11:51:24.205 debug (14257) 55000100026500 enocean.0 2021-02-01 11:51:24.188 debug (14257) Sent data: 55000c070196a5000001080000ffdc54840000ffb17b1eff00a3 enocean.0 2021-02-01 11:51:24.187 warn (14257) The data length for a 4BS telegram is incorrect. The length is 6 -
Hallo zusammen,
ich bin ganz neu in der enocean Welt undwürde mich über ein paar Tipps freuen!
Momentan habe ich an den Terassentüren Aqara Fensterkontakte kleben. über die Optik kann man sich streiten aber was mir fehlt ist auf jedenfall eine Erkennung der Griffstellung.Ich bin nun kurz davor mir entsprechende Teile zu besorgen. Den Usb-Stick habe ich bereits geordert.
Nun gibt es ja die "Standard" Hoppe Fenstergriffe wobei teilweise nur von offen/geschlossen Erkennung geschrieben wird und teilweise auch eine "gekippt" Erkennung. Diese bräuchte ich auf jedenfall!
Gibt es da eine klare Einordnung?Nun habe ich von Eltako noch die FFG7B gefunden.
Die würden mir optisch am besten gefallen, haben aber eine Batterie drin. Na Gut...
Leider ist dieser Typ nicht in der Liste der Unterstützten Geräte.
Wäre es möglich das der Typ unterstützt wird und was müsste man dafür tun?Vielen Dank!!
-
@schrubbel sagte in Test Adapter EnOcean (2) v0.3.x:
Wäre es möglich das der Typ unterstützt wird und was müsste man dafür tun?
Ja, Danke sagen (weitere Möglichkeit siehe signatur)
@schrubbel sagte in Test Adapter EnOcean (2) v0.3.x:
Nun gibt es ja die "Standard" Hoppe Fenstergriffe wobei teilweise nur von offen/geschlossen Erkennung geschrieben wird und teilweise auch eine "gekippt" Erkennung. Diese bräuchte ich auf jedenfall!
Gibt es da eine klare Einordnung?Soweit ich weis, wird die Fenstergriffstellung in allen 3 Positionen erkannt, so steht es auch in der Doku zu den Teilen.
-
@jey-cee Ein Danke gibts auf jeden Fall!
Ich wollte nur erstmal nachfragen wie die Chancen stehen bevor ich mir alles bestelle und ich im nachhinein gar nichts damit anfangen kann.
Ist das hier evtl. Hilfreich?Ich muss allerdings nochmal nachmessen ob der jetzige Vierkant lang genug ist.
Dieser Sensor ist mir eigentlich lieber als die Griffe da er seinen Status zyklisch sendet.
Dafür braucht er zwar ne Batterie aber die soll angeblich bis 7 Jahre halten -
komischerweise funzt der Rolladen jetzt... wie geb ich dem fud die Laufzeit vor, über RT?
-
@sepp sagte in Test Adapter EnOcean (2) v0.3.x:
wie geb ich dem fud die Laufzeit vor, über RT?
Ja, die Zeit ist Eingabe mal 100ms.
@sepp sagte in Test Adapter EnOcean (2) v0.3.x:
komischerweise funzt der Rolladen jetzt
Dann meintest du aber nicht den FUD14, weil das ist ein dimmer.
@schrubbel sagte in Test Adapter EnOcean (2) v0.3.x:
Ist das hier evtl. Hilfreich?
Danke für den Link, aber ich hab das schon erledigt und beide Varianten eingebaut.
-
@jey-cee natürlich -.- meinte den fsb^^,
habs gerade mal mit 10 probiert, sollte ja 1sec sein, dies hab ich im RT Feld bestätigt und dann unter cmd den auf Befehl geben, leider fährt er komplett auf.
-
@sepp
Moin - mal eine Frage zum Verständnis für mich: warum möchtest du den Rollladen über RT steuern? Das ist dann ja ein fest vorgegebener Wert, oder änderst du den dann jedesmal für eine andere Laufhöhe (per Script)?
Bei mir wird das dann irgendwann ein Script erledigen, welches vom definierten Punkt (ganz oben/unten) den Rollladen in die entsprechende Richtung nach einer bestimmten Zeit stoppt. Da meine Aktoren alle mit individueller Rückfallverzögerungszeit eingerichtet sind, erhalte ich eh keine RT-Meldung. -
@mustang so war eigentlich der Plan
Ich hatte ja für den wibutler die Laufzeiten für jeden Rolladen eingemessen. Jetzt wollt ich halt 5 sec fahren = ca die Mitte vom Fenster.
wäre vielleicht auch eine Idee, bin aber noch nicht so drin in der Programmierung -.-
Solltest du da eine Lösung haben kannst sie ja gerne mal hier posten
-
@sepp
Welche Visualisierung nutzt Du denn? Bei mir ist es Vis (vor allem zur Bedienung am Handy) und zur Automatisierung laufen bei mir dann Blockly-Scripte. Ich bin nun mal auch kein Programmierer, aber mit Blockly lässt das doch einigermaßen bewerkstelligen.
Hier mal ein schnell zusammengeklickter Schnipsel Für eine Zeitsteuerung, welche sich auch von Sekunden auf Millisekunden oder Minuten verändern lässt:
und als Blockly-Export:<xml xmlns="https://developers.google.com/blockly/xml"> <block type="comment" id=";4B$M)F8/+Eb+ct9,:Fs" x="-1137" y="-887"> <field name="COMMENT">Rollladensteuerung mit Stop nach x Sekunden</field> <next> <block type="controls_if" id="3]TY;pWN:)y4e`R8,XS%"> <value name="IF0"> <block type="logic_compare" id="cb+,IawqO},VVW(,e*oz"> <field name="OP">NEQ</field> <value name="A"> <block type="get_value" id="[Ta1^Z2TK]*;]7{sGqS$"> <field name="ATTR">val</field> <field name="OID">enocean.0.0584ab89.B0</field> </block> </value> <value name="B"> <block type="logic_boolean" id=",0Pu_Am7W|dHCw*C!IEC"> <field name="BOOL">TRUE</field> </block> </value> </block> </value> <statement name="DO0"> <block type="comment" id="dVjWfrh}F5[jTMdP^$],"> <field name="COMMENT">Up-Befehl</field> <next> <block type="control" id="{^vkXb5C!OqzRixz:@I1"> <mutation xmlns="http://www.w3.org/1999/xhtml" delay_input="false"></mutation> <field name="OID">enocean.0.0584ab89.CMD</field> <field name="WITH_DELAY">FALSE</field> <value name="VALUE"> <block type="math_number" id="{nDGTD-H)k7$umYo`V3Q"> <field name="NUM">1</field> </block> </value> <next> <block type="comment" id="rIEOU;P{_zUR:zN1*w):"> <field name="COMMENT">Stop-Befehl mit Wartezeit für Laufzeit Rolladen</field> <next> <block type="control" id="I`h,pv);]Z9nZ6}#[KaL"> <mutation xmlns="http://www.w3.org/1999/xhtml" delay_input="true"></mutation> <field name="OID">enocean.0.0584ab89.CMD</field> <field name="WITH_DELAY">TRUE</field> <field name="DELAY_MS">5</field> <field name="UNIT">sec</field> <field name="CLEAR_RUNNING">FALSE</field> <value name="VALUE"> <block type="math_number" id="T)2/!tXknsPb~lnVDY.B"> <field name="NUM">0</field> </block> </value> </block> </next> </block> </next> </block> </next> </block> </statement> </block> </next> </block> </xml>Das kannst Du so in Blockly importieren und brauchst nur noch die CommandID und Button B0 ändern. Button B0 benutze ich um festzustellen, ob die obere Endlage vor absetzen des Befehls erreicht wurde.
Da kannst Du denn ja noch diverse andere Bedingungen herum bauen, oder auch mehrere Aktoren ansprechen. -
@schrubbel said in Test Adapter EnOcean (2) v0.3.x:
Nun gibt es ja die "Standard" Hoppe Fenstergriffe wobei teilweise nur von offen/geschlossen Erkennung geschrieben wird und teilweise auch eine "gekippt" Erkennung. Diese bräuchte ich auf jedenfall!
Gibt es da eine klare Einordnung?Von Hoppe gibt es 2 Modelle. Der eine kann nur auf und zu detektieren, der andere auch gekippt. Letzterer ist teurer und die Platte ist deutlich größer. Hatte beide zum Testen und Erkennung klappte gut. Mussten letztendlich aber beide wieder zurück, da die Platten meiner Frau zu klobig waren.
