Habe mir auf gut Glück zwei Erfal HomeMatic Rollos geholt, weil mir die direkte Integration in HmIP gefiel. Grundsätzlich sind sie nicht schlecht, wirken hinreichend „wertig“ und der Motor fährt sanft und leise.
Blöde ist, dass diese Rollos nur für den Betrieb mit dem HmIP Access Point gedacht sind, aber ich natürlich eine Raspberrymatic benutze. Eigentlich funktioniert es mit etwas nervigem Herumkonfigurieren, aber es gibt in der Raspberrymatic-Oberfläche keine Möglichkeit den „Motor Endlageneinstellung“ Modus der Rollos zu aktivieren. Das müsste man grundsätzlich nur einmal machen, aber dafür muss ich jetzt die Rollos ablernen, an einen HmIP Accesspoint anmelden, mir die beknackte App holen, um dann darin auf den Knopf zu drücken, dann alles wieder ablernen (Endlageneinstellung bleibt zum Glück in dem Motorteil, der nicht beim Factory Reset gekillt wird gespeichert) und erneut an meine Raspberrymatic anlernen… plus die Direktverknüpfungen mit den Wandtastern wieder reparieren.
Ich muss nun zugeben, obwohl ich sehr viel HomeMatic (IP) einsetze und manches davon mit der Zeit „verstanden“ habe, dass ich nicht ganz verstehe, warum man nicht z.B. aus Symcon heraus ein „Signal“ absenden können sollte, um die Rollos in den Endlageneinstellungs-Modus zu bringen.
Die Instanz vom Rollo heißt SHADING_RECEIVER, was in der aktuellen Datenpunkt-Doku von HmIP nicht vorkommt. Es gibt dort lediglich ein paar „ähnliche“ Datenpunkte.
Gibt es irgendwie eine Möglichkeit, zu erkennen welche versteckten (write only/event) Datenpunkte es bei diesem undokumentierten Gerät noch geben könnte?
Das sind keine Datenpunkte, sondern Konfigurationsparameter. Somit bringt dich ein ‚SetValue‘ als RPC Kommando nicht weiter.
Ich habe inzwischen aber eine Möglichkeit die Parameter zu lesen/Schreiben. Komme nur nicht dazu das im Homematic Extended Modul fertig einzubauen.
Michael
Wir lesen diese Parameter theoretisch auch aus - nur erstellen keinen Variablen für die write-only Datenpunkte. Evtl könnte ich die ja ins debug werfen.
Ich kann mir gut vorstellen, dass es doch Datenpunkte (korrekte Terminologie?) sind, denn einerseits gibt es bei einigen anderen Aktoren SELF_CALIBRATION (oder so ähnlich) Datenpunkte als Write Only, die einen Motorkalibrierungsmodus triggern (habe auch schon geprüft ob es die selben bei dem Rollo gibt, leider nein).
Außerdem halte ich es für wahrscheinlich, dass die Endlageneinstellung nicht wirklich in dem Homematic IP Aktor gespeichert wird, sondern irgendwo in der Elektronik die den Motor ansteuert. Ich gehe davon aus, dass der Hersteller da eine existierende Elektronik mit einem zusätzlichen HmIP-Aktor „verbandelt“ hat.
Für letztere Vermutung spricht, dass die Endlageneinstellung bei Factory Reset erhalten bleibt.
Darum kann ich mir gut vorstellen, dass dieser spezielle Modus irgendwie „getriggert“ werden kann. In der HmIP-App (von dem Access Point gedönse) gibt es dafür einen Button.
Ich bekomme bald ein zweites solches Rollo und nehme es mir vielleicht einfach mal mit in die Werkstatt um mir die Elektronik mal anzusehen. Würde mich wirklich interessieren.
Wenn das ein Datenpunkt ist, dann wird es einer vom Typ ‚ACTION‘ sein und den kannst du per Script mit HM_WritevalueBoolean(ID, 'SELF_CALIBRATION', true);
ansteuern.
Ja, das ist mir bewusst, nur bei meinem Rollo heißt der zumindest nicht so. Eventuell heißt er anders (weil es keine selbstkalibrierung ist in dem Sinne).
Aber da der Aktor undokumentiert ist, kenne ich leider nicht alle Datenpunkte.
Die kannst du dir aber anschauen, wenn auch etwas umständlich.
Symcon fragt das Geräte nach seinen Datenpunkten, wenn du die Einstellung einer HM Instanz übernimmst.
Das kannst du im Debug des HM Socket sehen.
listValues oder getValues glaube ich.
Das XML von der CCU enthält dann alle Datenpunkte welche das Geräte meldet.
Michael
Ich habe das ausprobiert aber dabei kam nichts weiter zum Vorschein. Ich gehe mal davon aus, dass diese Datenpunkte auch „nur“ aus der CCU stammen. Dort ist die Darstellung dieses Aktors auch nur rudimentär.
Habe mir nun billig einen AP bei ebay geschossen und werde die Endlageneinstellung dann mal auf dem umständlichen Weg lösen. Warum das nötig ist, warum es für ein einzelnes Gerät keine halbwegs brauchbare Implementierung in der CCU gibt, ist mir wirklich unbegreiflich. Nutze HM und HmIP seit Jahren und habe so etwas noch nie erlebt. Wenn dann eher dass die Access Point Unterstützung fehlt. Aber dass es das auch umgekehrt gibt, spricht für eine wirklich undurchdachte Produktpolitik. Da weiß ja die rechte Hand nicht was die linke tut…
Ich habe das gleiche Thema.
Nun hatte ich einen AP und habe die Einstellungen gemnacht und nachher das Rollo in die Raspberrymatic zu nehmen; nur waren bei mir dann die Endpunkte weg bzw verstellt. Dann habe ich das derweilen aufgegeben und einen Taster direkt am AP angelent - damit kann man nun ohne AP die Rollos rauf und runterfahren, aber leider nicht in IPS steuern…
LG Alexander
Bevor ich das mache, nehme ich das Teil komplett auseinander und entwickle irgendeinen Hack… aber „die Cloud“ kommt mir nicht ins Haus
Ich werde berichten, wie es bei mir weiter geht.
Was ich bspw auch schon einmal gemacht habe, um mit meiner Keymatic-Fernbedienung von zu Hause auch bei meiner Werkstatt (einige Straßen entfernt) im dortigen HomeMatic-„Universum“ die Tür öffnen zu können, ist ein „Gateway“, der in beiden HomeMatic-Installationen angelernt ist und dann zwischen den beiden einen Tastendruck überträgt.
Das ist aber aufwändig zu bauen gewesen. Das mit dem Rollo werde ich irgendwie anders lösen.
Super, der HmIP AP den ich bei Ebay geschossen habe ist wohl defekt. Werde es nochmal an einem anderen Internetanschluss probieren, aber irgendwie mag die Cloud mich genau so wenig wie umgekehrt.
So, da wir ja hier ohnehin in OT sind, etwas Unterhaltung zwischendurch.
Der Ebay Verkäufer hat freundlicherweise den Preis erstattet ohne den defekten AP zurück haben zu wollen. Also habe ich ihn neugierhalber mal aufgemacht (ist das Silvercrest Modell).
Verbindet sich dann damit zwecks Upgrade auf Websocket, aber manchmal folgende Response:
HTTP/1.1 429 Too Many Requests\r\n
(passiert nicht wenn man einfach leere HTTP-Anfrage stellt)
Anschließend, falls WS Upgrade erfolgreich, instzabile Verbindung zur Cloud
-Viele Pakete vom AP an Cloud 62.113.249.71:80 werde nicht bestätigt und daher mehrfach wieder gesendet (kein ACK von Cloudseite)
-Es kommen teilweise Antworten von der Cloud mehrfach (ACKs) von Port 9292 (spurious retransmission)
Regelmäßig versucht der AP, den Schritt 1 (Lookup) erneut. Nach einer Weile macht er gar nichts mehr. LED in dieser Phase statisch gelb.
Manchmal klappt es, dass die LED zunächst blau leuchtet. Aber nach einigen Sekunden terminiert die Cloudseite dann die Websocket-Verbindung.
Also Ergebnis meiner wenig ergiebigen Analyse: Das Ding hat große Schwierigkeiten mit seiner Cloud zu quatschen oder umgekehrt. Nicht weiter hilfreich. Ich bestelle mir mal einen (hoffentlich) intakten AP und probiere ob ich damit was werde…
Interessant wäre zu wissen, ob der AP der nicht Silvercrest gebrandet ist, eine andere Response erhält (irgendwas ohne oem) und darum mit einer intakten Cloud sprechen darf.
Es gibt auf jeden Fall noch etliche weitere srz??.homematic.com, wie ich sehe.
(achtung unfundierte Mutmaßung über „defekte“ APs die es immer wieder mal zu geben scheint)
Könnte es so einfach sein, dass srz01 einfach überlastet ist und sich die Wahl der „Cloudadresse“ nach der SGTIN sowie der Frage ob OEM oder nicht richtet? So dass dann einige einfach Pech haben?
Ich mach das Wireshark Dings auf jeden Fall nochmal wenn ich den anderen AP habe, irgendwie interessiert es mich ja doch.
Habe mal zum Spaß einen DNS Proxy dazwischen gehangen und dem AP bei der DNS Query statt der IP zum srz01 die IP zum srz02 geschickt.
Führt zu einem dauerhaften Blinken der blauen LED, weil die Gegenstelle nun die Websocket-Verbindung sofort terminiert, aber es kommt nicht mehr zu Paketverlusten wie zuvor. Also auch keine gelbe LED mehr.
Spricht zunächst für meine Theorie, dass srz01 einfach total überlastet ist. Leider scheint es irgendeine Prüfung zu geben (ob der Domainname stimmt oder ob die SGTIN passt oder…) die verhindert, dass ich als AP mit einem nicht mir zugewiesenen Server per Websocket connecten kann.
Es bleibt spannend, werde den Test mal mit dem anderen AP wiederholen, wenn er da ist
Es ist nur ein Mikrocontroller, und dem wird nicht viel zu entlocken sein da er direkt mit dem Funkmodul kommuniziert, also alles encrypted. Etwas mehr Hoffnungen mache ich mir bei dem EEPROM. Darin dürfte neben anderen Settings auch die Endlageneinstellung gespeichert sein. Das Ding wäre per I2C ausles- und beschreibbar. Also falls ich tatsächlich feststellen sollte, dass die Endlageneinstellung beim Wechsel von Access Point auf CCU verloren geht, würde ich das mal eruieren… definitiv werde ich mir die I2C-Leitung zu dem EEPROM mal aus dem Gehäuse heraus führen, damit es möglich wird, da ran zu kommen wenn das alles wieder zusammen gebaut ist.
Die Demontage ist leider aufwändig, also eine simple Anleitung wird daraus wohl nicht werden
Mit Glück bekomme ich morgen einen funktionierenden AP; falls es mir damit gelingt, die Endlagen einzustellen und dies beim Umlernen nicht verloren gehen, baue ich das andere Gerät wieder zusammen und beende dieses Projekt.
Falls das jedoch nicht klappt, werde ich als nächstes die I2C-Leitung an den Logic Analyzer hängen und mal gucken, was wohin im EEPROM geschrieben wird bei der Endlageneinstellung.
Also, habe einen intakten AP bekommen und konnte feststellen: Das mit den Endanschlägen bleibt beim Ablernen vom AP gespeichert („Löschen“ in der HmIP App).
Insofern ist es etwas schade, dass meine Hacking-Ambitionen hier nicht weiter vonnöten sind, dafür kann ich aber die Rollos mit Einschränkungen (AP und Cloudgedöns für Ersteinrichtung erforderlich) immerhin empfehlen.
Die Endlageneinstellung ist auch etwas komplexer als „nur“ ein Knopf, da der Motor ja wie im Foto zu sehen über Hallsensoren verfügt, ist eine sehr präzise Einstellung möglich (wobei diese natürlich immer nur relativ sein kann, aber solange nicht jemand im stromlosen Zustand gewaltsam an dem Rollo reißt sollte sich eigentlich nichts verstellen).
Werde auf jeden Fall trotzdem mal die Wireshark-Analyse mit dem intakten AP wiederholen und berichten
