Rolladenaktor zum Jalousieaktor umkonfigurieren (und umgekehrt, Bl1PBU<->Ja1PBU)

Begonnen von Beta-User, 20 September 2017, 20:24:29

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo zusammen,

ich habe vor Jahren meine Rolladen und Jalousien mit dem damals alleine verfügbaren Rolladenaktor ausgerüstet (model: HM-LC-Bl1PBU-FM). Seit einiger Zeit gibt es auch einen Jalousieaktor, wobei beide dieselbe firmware nutzen.

Ich nutze HM mit CUL_HM und habe keine CCU2.

Nach  Auskunft des e3-Q-supports ist es möglich, (vermutlich eben mit einer CCU2), die firmware durch einen entsprechenden Befehl von der CCU2 aus anweisen, sich als Jalousie-Aktor zu konfigurieren (und umgekehrt). Dieser würde dann wieder als solcher auch von CUL_HM unterstützt.

Dazu bedarf es nach meinem Verständnis mehrerer Dinge, nämlich einmal muß  CUL_HM das entsprechende Register ansprechen können (die Register pcSlat und pctLvlSlat sind für den Rolladenaktor nicht verfügbar), und es müßten einige Register (bzw. die jumptable) umkonfiguriert werden (short- und longpress am Aktortaster selbst reagieren anders). Dazu wäre es vermutlich hilfreich, ein (bzw. zwei) template(s) zu haben, das die Register passend konfiguriert.

Meine Vermutung wäre, dass es eine Art "Basisparameter" gibt, aus dem sich für den Aktor ergibt, ob er sich als Jalousie- oder Rolladenaktor ausgibt. Jedenfalls scheint es NICHT unveränderlich zu sein bzw. irgendwo im Bootloader verankert.

Wenn möglich, wollte ich es vermeiden, nur zum Umkonfigurieren der 4 Aktoren, um die es mir hier geht, extra eine OCCU aufzubauen.

Gedanke dazu:
Vielleicht kann jemand, der sowohl eine CCU2 wie einen CUL (oä.) hat, die raw-Messages sniffen? Wenn man die hat, sollte es doch an sich möglich sein, die Umschaltfunktion in CUL_HM einzubauen, oder sitze ich da einem Irrtum auf?

Wenn mir jemand erklärt, wie es geht und es jemandem anderen später hilft, mache ich das mit dem Sniffen auch sebst...

Gruß und ggf. Danke vorab für eure Hilfe,

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

martinp876


Beta-User

Das war die Rückmeldung des e3-Q-supports:

ZitatNachdem ein Gerätefirmware-Update auf die vorliegenden Rollladenaktoren aufgespielt wurde, kann unter:

Einstellungen -> Geräte -> "Rollladenaktor" -> Einstellen

die Aktion auf Lamellenverstellung umgeschaltet werden. Der Aktor wird nun durch einen kurzen Tastendruck
die Lamellen kippen und durch einen langen Tastendruck die Jalousie herauf oder herab fahren.
Das sollte in der CCU2 also möglich sein...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

martinp876

Ok. Alles klar .kann man in ein template integrieren. Idee ist einfach .1s zu fahren. Kann jeder rolloaktor.

Beta-User

Ich bin mir nicht sicher, ob ich deine Antwort richtig verstanden habe.

Dass das mit den bestehenden Registern grundsätzlich möglich ist, einen kurzen Tastendruck anders zu belegen, ist schon klar.

Meine Arbeitshypothese ist aber eine etwas andere, nur leider kann ich sie nicht ohne entsprechenden Aufwand (CCU2/OCCU) verifizieren:
Schreibt man in das Register "Lamellenaktion" einen anderen Wert als "0", meldet sich der Aktor nicht mehr als klassischer Rolloaktor, sondern als Jalousieaktor (und umgekehrt, wenn auf "0" gesetzt). Es wird also (in der CUL_HM-Welt) der Gerätetyp selbst umgestellt. Da dieses Register unter CUL_HM gar nicht sichtbar zu sein scheint (?), kann man das nicht so ohne weiteres setzen (da fällt mir ein: mit einem entsprechenden RAW-Befehl könnte es eventuell gehen).

Damit sollten dann auch die weiteren Register bzw. Fahrbefehle zur Verfügung stehen, die es unter CUL_HM für den Jalousieaktor schon gibt (ich vermute: die Drehzeit ist einstellbar, man kann dann von FHEM aus auch eine Lamellendrehung veranlassen und die Fahrzeiten passen besser, weil der Aktor ja weiß, ob er erst eine Drehung machen muß, bevor die eigentliche Fahrt beginnt).

Testweise kann ich gerne mal versuchen, einen der Rolladenaktoren mit RAW-Kommandos zu füttern. Tippen würde ich darauf, dass eventuell eine Drehzeit für die Lamellen ausreichend sein könnte, oder es gibt eben ein gesondertes "bool"-Register.

Die reine Umkonfiguration des Rolloaktors (bzw. der Taster) ist nach meinem Empfinden dagegen nur eine Notösung.

Ich hoffe, mich halbwegs verständlich ausgedrückt zu haben.

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

martinp876

Ich habe es mit der ccu probiert. Allerdings habe ich kein Register dieses Namens gesehen.
Ich konnte ein template aktivieren.
Wichtig ist zu wissen, bei welchen Aktor und welcher fw das funktionieren soll. Welche ccu2 Version ist notwendig.
Rolloaktor ist nicht gleich rolloaktor.

Beta-User

Also zu meinen Rolloaktoren hier mal ein exemplarisches list, die sind alle gleich. Ich gehe davon aus, dass sich die Aussage des Services auf die aktuelle fw-Version bezog (sollte nach meiner Kenntnis 2.11 sein, die ist bei meinen auch drauf) sowie eine halbwegs aktuelle CCU2:
Internals: CFGFN CUL_0_MSGCNT 72 CUL_0_RAWMSG A0C79A0102A4820425EE2030000::-71:CUL_0 CUL_0_RSSI -71 CUL_0_TIME 2017-09-21 22:50:00 DEF        2A4820 IODev      CUL_0 LASTInputDev myHmUART MSGCNT     144 NAME       Jalousie_Mitte NOTIFYDEV  global NR         329 NTFY_ORDER 50-Jalousie_Mitte STATE      on TYPE       CUL_HM lastMsg    No:79 - t:10 s:2A4820 d:425EE2 030000 myHmUART_MSGCNT 72 myHmUART_RAWMSG 0500004979A0102A4820425EE2030000 myHmUART_RSSI -73 myHmUART_TIME 2017-09-21 22:50:00 peerList   Schalter_WZ1_Btn_05,Schalter_WZ1_Btn_06, protLastRcv 2017-09-21 22:50:00 protResnd  4 last_at:2017-09-21 22:49:54 protSnd    92 last_at:2017-09-21 22:50:00 protState  CMDs_done rssi_at_CUL_0 avg:-70.65 max:-69 lst:-71 cnt:72 min:-72 rssi_at_myHmUART avg:-73.61 max:-71 lst:-73 cnt:72 min:-76 rssi_myHmUART avg:-84 max:-84 lst:-84 cnt:1 min:-84 READINGS: 2017-09-21 22:49:43   CommandAccepted yes 2017-09-21 22:49:33   D-firmware      2.11 2017-09-21 22:49:33   D-serialNr      LEQ0219635 2017-09-21 22:49:55   PairedTo        0x425EE2 2017-09-16 14:43:12   R-Schalter_WZ1_Btn_05-lgActionType jmpToTarget 2017-09-16 14:43:12   R-Schalter_WZ1_Btn_05-lgOnLevel 100 % 2017-09-16 14:43:12   R-Schalter_WZ1_Btn_05-shActionType jmpToTarget 2017-09-16 14:43:12   R-Schalter_WZ1_Btn_05-shOnLevel 100 % 2017-09-16 14:43:13   R-Schalter_WZ1_Btn_06-lgActionType jmpToTarget 2017-09-16 14:43:13   R-Schalter_WZ1_Btn_06-lgOnLevel 100 % 2017-09-16 14:43:13   R-Schalter_WZ1_Btn_06-shActionType jmpToTarget 2017-09-16 14:43:13   R-Schalter_WZ1_Btn_06-shOnLevel 100 % 2017-09-16 14:43:10   R-driveDown     66 s 2017-09-16 14:43:10   R-driveTurn     1.5 s 2017-09-16 14:43:10   R-driveUp       70 s 2017-09-21 22:49:55   R-pairCentral   0x425EE2 2017-09-16 14:43:10   R-powerUpAction off 2017-09-16 14:43:10   R-sign          off 2017-09-21 22:49:55   RegL_00.          02:01 0A:42 0B:5E 0C:E2 15:FF 18:00 00:00 2017-09-21 22:49:56   RegL_01.         08:00 09:00 0A:00 0B:02 0C:94 0D:02 0E:BC 0F:0F 10:00  30:06 57:06 56:00 00:00 2017-09-21 22:49:57   RegL_03.Schalter_WZ1_Btn_05  01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:44 0C:54 0D:93 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:93 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:44 8C:54 8D:93 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:05 9E:93 9F:00 00:00 2017-09-21 22:49:59   RegL_03.Schalter_WZ1_Btn_06  01:00 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:11 0C:12 0D:68 0E:00 0F:00 11:C8 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 1A:00 1B:00 1C:00 1D:FF 1E:68 1F:00 81:00 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:11 8C:12 8D:68 8E:00 8F:00 91:C8 92:00 93:00 94:00 95:00 96:00 97:00 98:00 99:00 9A:00 9B:00 9C:00 9D:05 9E:68 9F:00 00:00 2017-09-16 14:42:25   deviceMsg       on (to VCCU) 2017-07-22 16:23:01   fwUpdate        fail:Block1 2017-09-16 14:42:25   level           100 2017-09-16 14:42:25   motor           stop:on 2017-09-16 14:42:25   pct             100 2017-09-21 22:49:56   peerList        Schalter_WZ1_Btn_05,Schalter_WZ1_Btn_06, 2017-09-16 14:42:25   recentStateType info 2017-09-16 14:42:25   state           on 2017-09-16 14:42:25   timedOn         off helper: HM_CMDNR   121 cSnd       01425EE22A4820010420CED50503,01425EE22A4820010420CED50603 mId        006A peerIDsRaw ,20CED506,20CED505,00000000 rxType     1 supp_Pair_Rep 0 ack: dir: cur        stop expert: def        1 det        0 raw        1 tpl        0 io: newChn     +2A4820,00,00,00 nextSend   1506027000.3758 rxt        0 vccu       VCCU p: 2A4820 00 00 00 mRssi: mNo        79 io: CUL_0      -69 myHmUART   -73 prt: bErr       0 sProc      0 rspWait: q: qReqConf qReqStat role: chn        1 dev        1 prs        1 rpt: IO         CUL_0 flg        A ts         1506026999.98599 ack: HASH(0x4156d00) 798002425EE22A482000 rssi: at_CUL_0: avg        -70.6527777777778 cnt        72 lst        -71 max        -69 min        -72 at_myHmUART: avg        -73.6111111111111 cnt        72 lst        -73 max        -71 min        -76 myHmUART: avg        -84 cnt        1 lst        -84 max        -84 min        -84 shadowReg: tmpl: Attributes: IODev      CUL_0 IOgrp      VCCU:CUL_0 JalousieTurnValue 3 WindowContactAssociated Terrassentuer_EZ WindowContactOpenMaxClosed 85 WindowContactTiltedMaxClosed 40 autoReadReg 4_reqStatus devStateIcon on:fts_shutter_10 off:fts_schutter_100 expert     2_full firmware   2.11 fp_Erdgeschoss 421,913,0, group      Türen und Fenster icon       fts_shutter model      HM-LC-Bl1PBU-FM peerIDs    00000000,20CED505,20CED506, room       Esszimmer serialNr   LEQ0219635 subType    blindActuator userattr   room_map structexclude WindowContactAssociated WindowContactOnHoldState WindowContactOpenMaxClosed WindowContactTiltedMaxClosed WindowContactTiltedMaxClosed JalousieTurnValue JalousieTurnValue WindowContactTiltedMaxClosed webCmd     toggle:on:off:up:down:stop:statusRequest
Die Aussage des Services hatte ich so verstanden, dass es irgendwo in der CCU einen entsprechenden Menüpunkt gibt, kann das aber mangels CCU(2) nicht verifizieren.

Beim weiteren Nachdenken bin ich auf die Idee gekommen, bei CUL_HM einfach mal so zu tun, als wären beide Aktoren-Typen identisch. Leider bin ich nicht so der perl-Held, aber der Versuch wäre in die Richtung gegangen, den alias in HMinfo.pm zu ändern oder bei der nummerischen Zuordnung die Jalousienkennung zu verwenden? Oder wo nimmt CUL_HM die Infos her, welche Register es überhaupt gibt?

Dann sollten beim Neupairen des Aktors ja die Readings angelegt werden und ich hätte einfach mal versucht, via getConfig rauszufinden, was in den Registern steht und dann evtl. das pctSlat einfach mal zu nutzen und zu sehen, was passiert. Vielleicht reicht das ja schon...

Oder ist mein gedanklicher Ansatz an sich falsch?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

So, HMConfig.pm habe ich mal in Zeile 180 angepaßt (alias=>'HM-LC_Ja1PBU-FM'}, so dass die entprechenden Befehle sichtbar sind.
Eine Reaktion auf pctSlat erfolgt leider nicht, wie pctLvSlat sinnvoll zu beschicken wäre, dazu fehlt mir eine Idee.

Habe mal die raw-Register abgefragt, für den Fall, das das was hilft:
ZitatRegL_00.
   
02:01 0A:42 0B:5E 0C:E2 15:FF 18:00 00:00
   
2017-09-21 23:20:48
RegL_01.
   
08:00 09:00 0A:00 0B:02 0C:94 0D:02 0E:BC 0F:0F 10:00 30:06 57:06 56:00 00:00
   
2017-09-21 23:20:49
Der Rest brachte keine sinnvollen Ergebnisse bzw. in Regl03 stehen Angaben zu einem gepairten Schalter.






Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

martinp876

Das. Wäre auch erstaunlich.
Es gibt unterschiedliche blind Aktoren. Deinen Typ kenne ich immer noch nicht.
Ich habe tbu. Die ccu2 bietet kein Register an, welches auf Umschalten hindeutet.
Die ccu bietet ein template an, welches die Tasten konfiguriert, also die Register der Peers setzt.
Dein Vorgehen, die Kennung im hmconfig umzusetzen um die Identität eines Aktors zu ändern war korrekt- nur sinnlos. Nur weil man fhem glauben macht der Aktor sei ein anderer kann der Aktor nicht mehr.
Die Register werden dynamisch aus dem device gelesen und von fhem nach regeln interpretiert. Ich kenne keine neuen unbekannten Register.
Nachdem auch die ccu2nichts anbietet scheinst du auf dem Holzweg zu sein.

Angeboten wird eine jalousieunterstützende Nutzung der Tasten und Peers. Mit kurz kann man eine minimale Bewegung erzielen, mit lang das komplette öffnen, schließen.
Ich habe auf die schnelle ein (zwei) Templates gebastelt, die das realisieren ( template Editor macht's möglich). Kann ich bei Gelegenheit veröffentlichen. Das Prinzip hatte ich schon länger in Betrieb.
Mit Kommandos wird es allerdings schwierig, da im Gegensatz zu Peer Register hier keine absolute Zeit in der sondern eine relative Aktion in Prozent eingetragen wird. Geht also nicht gut mit Kommandos.
Auch wichtig: der Aktor kennt keine Drehung ( im Gegensatz zu Jalousie) . Das muss man mit allen Ungenauigkeiten selbst Rechnen. Geht nie genau!!!

Beta-User

Irgendwie schade, und ich mag auch noch nicht so recht glauben, dass das wirklich nicht geht.

Wenn es geht, geht es NUR mit "meinem" Typ Rolloaktor (HM-LC-Bl1PBU-FM) oder mit einem HM-LC-Ja1PBU-FM (ganz vielleicht noch mit einem HM-LC-Sw2PBU-FM, dazu gleich).

Diese beiden nutzen  dieselbe Firmware, jedenfalls wenn man dem  Changelog Glauben schenkt (hier taucht verwirrenderweise u.a. auch der og. Sw2 auf). Von daher sollten alle beiden (bzw. 3 Aktoren) intern dieselben Parameter verarbeiten können, also grundsätzlich auch das Drehen von Lamellen auf eine bestimmte Zeit x von y ähnlich einem intern berechneten "on-for-timer".
Zitat
Version 2.10.0 - 20160810
--------------------------------------------------------------
** Modification
   * Support for HM-LC-JaPBU-FM
     
** Improvement
     * Increased accuracy of internal level at blind actuators

Hmm.. Ich seh' grade, dass da das "1" fehlt, aber den Aktor in der Schreibweise des Changelogs gibt es gar nicht....
Hast du denn einen Ja1PBU, bei dem die vom support genannte Option (umgekehrt) in der CCU2 auftauchen müßte?
Nur die Funktion von short- und longpress zu tauschen, ist nicht sooo spannend, da sich alle hier an die Tastenfunktionen gewöhnt haben. Richtig interessant wäre  die Möglichkeit, die Jalousiendrehung von FHEM aus zu machen, und das ist mit der bisherigen Funktionalität bescheiden, da FHEM nicht auf Aktionen im ms-Bereich zugeschnitten ist.

Danke jedenfalls für das Mitdenken!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

#10
Dennoch würde mich noch interessieren, welche Parameter für pctLvSlat als Art Standardwert bei einem HM-LC-Ja1PBU-FM anzusehen wären, damit ich das testweise mal so setzen kann. Edit: das scheint hier beschrieben zu sein. Werde daher als nächstes mal versuchen, "refRunTimeSlats" mit einem Wert>0 zu befüllen, vielleicht mag er die slat-Befehle dann ::) .

Und dann, auch wenn das uU. böse ins Auge gehen kann:

Die Kennung der Aktoren steht - vermutlich bei allen HM-Aktoren - im selben Register, das auch in der OCCU als "read-only" (const_value) hinterlegt zu sein scheint.
Auch wenn das SW-seitig nicht vorgesehen ist, heißt das ja nicht, dass der Aktor einen Schreibebefehl eventuell nicht doch verarbeiten würde, also: wie müßte ein (raw-) Schreibbefehl aussehen, um das zu ändern?
Ich würde dann den Test machen, ob der Aktor sich dann anders verhält, wenn man dort statt "0x006A" "0x0107" reinschreibt. Kann zwar schiefgehen, aber wenn es ginge und nicht den erhofften Effekt hat, sollte sich das eigentlich auch wieder rückwärts ändern lassen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

papa

Ich glaube das geht so nicht. Wenn DU das hier aus dem XML meinst:


<type name="radio-controlled jalousie actuator 1-channel (flush-mount)" id="HM-LC-Ja1PBU-FM" updatable="true" priority="2">
  <parameter index="9.0" size="1.0" cond_op="GE" const_value="0x29"/>
  <parameter index="10.0" size="2.0" const_value="0x0107"/>
</type>


Das sagt nur, dass in der DeviceInfoMessage an Stelle 9 die Firmwareversion und an der Stelle 10/11 die ModelID (2 Byte) stehen. Das sind also keine Register sondern Daten in einer Message.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

Beta-User

Danke für die Klarstellung, die Angabe aus dem XML war gemeint. Nachvollziehbar, dass das keinen Rückweg darstellt.

Bleibt also nur der Versuch, mal einfach einen Wert in refRunTimeSlat zu schreiben und zu sehen, ob wenigstens dieses Register tatsächlich besteht und nur irgendwie verborgen ist, ich berichte ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

martinp876

Fhem liest immer ALLE Register. Sollte es dies geben wird es gelesen. Es wird nicht dekodiert, das ist alles.
Du kannst die rohregister ansehen und erst einmal prüfen, ob es da ist. Sollte es da sein muss es noch nicht funktionieren.

Aber ehrlich: ich habe keine Hoffnung. Dabei brauche ich die Funktion auch.
Wenn man es umstellen könnte, warum sollte eq3 so rumzicken? Es umschaltbar machen? Eine clevere fw sollte die hw identifizieren können und sich danach einrichten. Die gleiche fw auf unterschiedlicher hw muss lange nicht das gleiche tun. Sollte die hw die Funktion unterstützen könnte eq3 es einfach freischalten. Warum Umschalten?

Macht alles keinen Sinn.