Schellenberg Smart Home Zentrale SH1 in FHEM einbinden

[fatbrother]

Hallo,

ich habe mir den Funk-Alarmgriff von der Firma Schellenberg gegönnt. Ich finde das Produkt einzigartig. Glasbruch- und Hebelversuche an Fenster(türen) werden mit einem Alarm (vergleichbar mit Rauchmelder) quittiert. Aus meiner Sicht eine gute Ergänzung, wenn mechanischer Schutz schon gegeben ist.

Grundsätzlich funkt der Griff auf der 868 Mhz Frequenz, es sollte möglich sein, ihn in FHEM einzubinden um sich die 300€ teure und Herstellerspezifische Smart Home Zentrale SH1 zu sparen. Grundsätzlich ist es interessant zu sehen, ob die Fenstertür geschlossen, offen oder auf Kipp steht, was der Griff unterscheiden kann und die Alarmfunktion dementsprechend an- oder aus schaltet. Das erspart neben dem Einbruchsschutz dann gleich die Fenstersensoren, die es ja von diversen Anbietern gibt (optisch nicht mein Fall).

Im Forum finde ich nichts zur SH1. Hat jemand Infos oder interessante Links?

Euer Fatbrother

[rudolfkoenig]

Grundsätzlich funkt der Griff auf der 868 Mhz Frequenz, es sollte möglich sein, ihn in FHEM einzubinden um sich die 300€ teure und Herstellerspezifische Smart Home Zentrale SH1 zu sparen.

Kenn ich auch von meinem Chef: ist doch sinnvoll,  muss also einfach sein, ich will es haben, mach mal.
Wenn eine Firma ein Sicherheitsprodukt heutzutage ohne Verschluesselung auf dem Markt wirft, dann ist was faul. Sie zu brechen ist evtl. moeglich, erfordert aber viel Aufwand und/oder Glueck. Und Erfahrung. Aber das kommt ja mit der Zeit.

[fatbrother]

Danke für die Antwort. Verstehe ich dich richtig, dass es keine bisherige Einbindung gibt, weil die Schellenbergprodukte verschlüsselt kommunizieren und das noch nicht geknackt wurde?

[rudolfkoenig]

Das ist nur mein Gefuehl, ohne etwas untersucht zu haben.

[Waldmensch]

Wär schon doof, wenn Sicherheitstechnik unverschlüsselt funkt. Reicht ja, wenn ich meinem Nachbarn  zur Bescherung den Christbaum ein/ausschalten kann, den er über eine FS20 Steckdose betreibt.


Gesendet von iPhone mit Tapatalk

[fatbrother]

Völlig d'accord mit eurer Einschätzung. Habe mal den Schellenberg Support diesbezüglich kontaktiert. Verschlüsselung wurde bejaht, als ich nach Details gefragt habe, musste gepasst werden. Der zuständige Kollege komme erst nach den Feiertagen zurück und will dann meine Fragen beantworten. Mal sehen. Seine Antwort poste ich gerne ein wenig Offtopic hier im Forum wenn gewünscht.
Fatty

[herrmannj]

wie funktionieren die Griffe denn ?

Kann man die Urlaubsfunktion zb über die Zentrale aktivieren oder macht man das am Griff ? Die Frage bezieht sich darauf ob die nur senden oder auch empfangen können.

Hilfreich wären hochauflösende Fotos der verwendeten Platine (Transmitter oder Transceiver).

Zu den Glasbruch (Erschütterungssensoren): Ich habe eine Front die so aussieht: Tür/Fenster/Fenster/Tür. Das bedeutet der Griff müsste die Tür und das daneben liegende Fenster (Vollfäche, gleicher Rahmen) mit in Bezug auf Glasbruch absichern. Meinst Du die können das ?

Ich könnte mir vorstellen mir die Griffe im Q2 mal vorzunehmen.

vg
joerg

[fatbrother]

Hallo zusammen,
anbei die Antwort der Firma Schellenberg.
Das sollte die Fragen von Hermannj beantworten. Wenn noch was offen ist bitte kurz aufzeigen, wird dann beantwortet.
Gruß Fatty

---

Frage 1.   Wird sämtliche Kommunikation verschlüsselt? Mit welcher Stärke? Wird ein öffentlich bekanntes und als sicher angesehenes Protokoll genutzt? Welche Standards?

Folgende Kommunikationswege werden im Schellenberg Smart Home-System genutzt:
Kommunikationsweg App à Schellenberg-Produkt
    Die App ist für die Betriebssysteme Android (ab Version 4.4) und iOS (ab Version iOS8) verfügbar
    (A) Von der App auf dem Smartphone oder Tablet wird ein Befehl versendet, der über das hauseigene WLAN-Netz an den Router weitergetragen wird
    oder (B) Von der App auf dem Smartphone oder Tablet wird ein Befehl versendet, der über das mobile Internet von überall an den Router weitergetragen wird
    (C) Der Router gibt den Befehl über das LAN-Kabel an die SH1 Box weiter
    (D) In der SH1 Box ist softwareseitig ein Übersetzer integriert, der das LAN-Protokoll in unser Funkprotokoll Schellenberg Radio System (SRS) übersetzen kann. Sobald der Befehl in unsere Funksprache übersetzt wurde, wird der Befehl an die entsprechenden Produkte versendet

Jeder Kommunikationsweg ist verschlüsselt:

WLAN: Das WLAN muss jeder Benutzer selber absichern. Meistens sind die Router schon standardmäßig auf verschlüsseltes WLAN (WEP, WPA2 etc.) konfiguriert. Es muss auch ein sicheres WLAN-Passwort vergeben werden. Die Verbindung von der App zu SH1-Box erfolgt immer verschlüsselt über TCP per TLS

Mobiles Internet/Fernzugriff: Alle Verbindungen von App zu der SH1-Box, ob im WLAN oder per Funktion Outdoor Control sind nach TLS-Standard verschlüsselt. Die genaue Chiffrierung (z.B. 256 Bit) wird erst zwischen App und SH1-Box ausgehandelt (handshake).

Schellenberg Radio System: Proprietäres Funk-Protokoll, Rolling Code ähnlich key lock, verschlüsselte Geräte-ID


Frage 2. Werden Passwörter nicht im Klartext gespeichert / übertragen, sondern nur Hashwerte oder ähnlich?

Passwörter werden immer nur gehasht übertragen oder gespeichert. Hierfür wird auch salt und session salt verwendet, um brute force Angriffe mit rainbow table auszuschließen.


Frage 3. Planen Sie Updates zur Verfügung zu stellen, sofern beim eingesetzten Verfahren später Schwachstellen gefunden werden?

Ja, selbstverständlich überprüfen wir die Aktualität der Sicherheitsanforderungen und passen diese im Bedarfsfall umgehend an.

[herrmannj]

Moin,

vielen Dank. Das schöne an dieser community: man lernt viele neue Sachen kennen.

Die Griffe finde ich gut. Danke für Deine erste Erkundung dazu. Ich habe mir im Baumarkt die (funklose) Version auch mal angeschaut.

Ich werde mir die (Funkvariante) wohl auch holen (bin noch nicht ganz sicher aber schon etwa) und "irgendwann" auch mal schauen ob man die einbinden kann. Irgendwann bitte genauso verstehen wie ich es meine - ich will da keine falschen Erwartungen.

Wenn jemand mitmachen möchte: sehr gern! Ob es überhaupt geht wird man auch erst wissen wenn man es versucht. Sollte es also Interessenten geben die sich beteiligen wollen bekommen wir das vmtl schneller hin.

So könnte der Weg aussehen (ich gehe von der Anbindung ohne die sh1 Zentrale aus):

Zuerst ist es notwendig zu verstehen wie die Griffe funken. Die Freuquenz (hier 868Mhz) ist nur ein unwesentlicher Parameter. Wichtig ist zu verstehen mit welchem Modulationsverfahren und mit welcher bitrate und evtl welchen Sync-wörtern das passiert.

Dazu ist es zuerst grundsätzlich sehr hilfreich zu verstehen welcher Funkchip in den Griffen verwendet wird (aufschrauben, nachschauen, forografieren). IdR ist das ein CC1101 oder ein rfm68/69. Manchmal auch was ganz anderes, aber selten. Wenn man das weiß kann man die Möglichkeiten schon etwas eingrenzen. Es gibt Datenblätter dazu und Referenzdesigns und aus denen bedienen sich auch die Entwickler.

Mit diesem Wissen kann man dann entweder die Initialisierungssequenz auf dem SPI Bus mitlesen (und anhand der Register, siehe Datenblatt) die Funkparameter verstehen oder (optimal und) einen SDR Empfänger aus eine alten USB TV Karte, einem Notebook und frei verfügbarer Software zusammenstecken. An diesem SDR Empfänger kann man auch viel über das verwendete Funkverfahren (Modulation, etc) sehen.

Wenn man das alles hat gilt es einen Empfänger für fhem zu finden. Ein CUL oder ein Jeelink, die speziell justiert werden sollten passen. Ob der Aufwand Null oder größer ist hängt eben von dem ab wie der Griff genau sendet.

Wenn soweit alles gut ging hat man schon mal eine Kette von Nullen und Einsen mit denen man arbeiten kann.  Die Antwort von Schellenberg

Schellenberg Radio System: Proprietäres Funk-Protokoll, Rolling Code ähnlich key lock, verschlüsselte Geräte-ID

finde ich schon mal gut - die meisten Hersteller drucksen rum oder schwirbeln bla-bla. Das Schellenberg hier schon mal zackig fachlich antwortet ist echt ok, anerkennenswert.

Davon sollte man sich aber nicht abschrecken lassen. Besonders hilfreich ist an so einer Stelle zu verstehen wie die Anmeldung an einer Schellenberg sh1 Zentrale funktioniert.

Beispiel:
"verschlüsselte Geräte-ID". Yepp. Die Zentrale muss ja aber auch verstehen was sich da meldet wenn ein Griff angelernt wird. Verschlüsselt kann(!) in dem Zusammenhang durchaus meinen das die ID des Griffes mit einem XOR behandelt wurde. Das macht aber nichts - solange die von Funktelegramm zu Funktelegramm gleich bearbeitet ist spielt das überhaupt keine Rolle.

"Rolling Code". Yepp. So sieht so etwas aus: https://de.wikipedia.org/wiki/Keeloq und heißt dann auch nicht Key Lock sondern keeloq, but anyway, war ja auch der Support und der hat sichtlich den Hörer in die Hand genommen und mal bei PM oder DEV nachgefragt. Echt: Hut ab. Da ist jetzt auch die Frage was denn genau mit dem Rolling Code gemacht wird. Er kann als Basis genommen werden um die gesamte Nachricht zu verschlüsseln. Das wäre dann doof . Er kann aber auch ein Teil der Nachricht sein wo der Sender dem Empfänger einfach nur seine Echtheit beweist. Für fhem könnte(!) das bedeuten das man den Alarm (oder den Status) des Griffes in einer lesbaren Form findet (ohne das es möglich wäre durch den rolling code die Echtheit der Nachricht zu püfen). Für einen Einbruchsalarm fände ich das (zur Not ) akzeptabel und praktikabel. Einer Arm/Disarm Nachricht müsste man ja nicht vertrauen. Die nächste Frage der man sich zuwenden kann ist die Implementierung des Rolling codes selber. Conrad RSL benutzen auch Rolling codes und lassen sich trotzdem von Community Sendern schalten

Mir ging es zum einen darum mal aufzuzeigen warum man jetzt so etwas nicht "im Vorbeigehen" einbinden kann. Zum anderen aber auch den usern die Interesse haben Einstiegspunkte zu zeigen wo man ansetzen kann wenn man sich beteiligen möchte (geht ja um community hier;) )

Vielleicht kennt sogar jemand weitere Ansätze ....

vg
joerg

[Waldmensch]

Wenn der Hersteller clever ist, bietet er irgendwann einen Dongle an, der die normale Kommunikation readonly am PC anbietet. Dann muss keiner den Kram hacken, der Hersteller kann was am Dongle verdienen, für FHEM Nutzer werden die Griffe hochinteressant. Ich würde gleich für 12 Stück Bedarf anmelden.

Wie erfolgreich dieses Prinzip der Öffnung für Communities sein kann, sieht man an den Sonoff Geräten. Wer nutzt denn die Originale Itead Software?

Gesendet von iPhone mit Tapatalk

[fatbrother]

Hallo herrmannj,

da ich selber in der IT arbeite, kann ich sowohl dein Vorgehen verstehen, als auch die Fristigkeit bewerten. Keine Sorge, das trifft auf verständnisvolle Ohren und natürlich vielen Dank für die Details. Um dich zu unterstützen, werde ich kurzfristig auch noch in diesemThread bei demontiertem Griff ein Foto posten.

Außerdem noch ein Nachtrag der Firm Schellenberg, da ich noch eine Rückfrage hatte:
Frage: Welche Kosten entstehen für die Nutzung der Zentrale? Ist diese bereits IPv6 fähig?
Antwort: Für die Nutzung des Smart Home Systems fallen keine weiteren Kosten an ausser die Erstbeschaffung. Wenn Sie die Outdoor Control funktion nutzen möchten, fallen fü 2 Jahre 19,99€ an, dies ist kein Abo. Die SH1 ist bereits auf dem neusten Standard also auch IPv4 und 6 fähig.

Gruß Fatty

[fatbrother]

Guten Abend,

anbei die Fotos. Zwei Platinen habe ich gefunden in einem Alarmgriff.

Trotz großer Vorsicht und keine direkten Kontakte war der Griff danach unbrauchbar. Mal sehen, was mein Händler dazu sagt.

Mich überzeugen die Dinger aber sehr. Eine FHEM Integration ist vor allem finanziell interessant, da nicht nur die 300 € für die Zentrale, sondern auch die 20€/24 Monate für den Remotezugriff gespart werden könnten.

Euer Fatty

[herrmannj]

Das gibt mindestens das purple heart. Ich vermute da ist bei Zusammenbau was schief gegangen, ich drücke Dir die Daumen das sich das korrigieren lässt. Vom Anfassen der Platine geht die nicht kaputt.

Einen Funkchip kann ich auf die schnelle nicht identifizieren aber ich sehe etwas anderes ganz interessantes. Schau Dir mal den thread an: https://forum.fhem.de/index.php/topic,39534.0.html

So wie ich das auf der Platine sehe scheint Schellenberg den Griff OEM von Soda zu beziehen. Den wiederum haben die Kollegen aus dem Nachbar-thread schon  als enocean am laufen. enocean kann wohl auch rolling codes (https://de.wikipedia.org/wiki/Enocean), insofern wäre die Aussage von Schellenberg auch konsistent.

Nun will ich nicht ausschließen das Schellenberg ein spezielles Protokoll programmieren lassen hat.

Schau Dir doch den verlinkten thread mal an, evt musst Du mal mit den Jungs dort sprechen ob Du das irgendwie testen kannst oder einen enocean stick bestellen. Zur Not könntest Du die Schellenberg Griffe ja gegen die Soda tauschen (sind wohl bau- und preisgleich).

Das scheint alles viel fixer zugehen als wir dachten, wenn das so ist braucht keiner sniffen und reverse zu suchen.

vg
joerg

[pm100]

Kann sein das die Stellung der drehenden Platine nicht passt.

Ist ein CC1101 drauf, wird AM moduliert. Der CC1101 wird nur als Sender/Empfänger verwendet. Dekodieren tut es der
ATSAMD20 Prozessor. Protokoll ist was eigenes. Beginnt mit 5ms Puls und dann folgen eine ganze Menge kurzer Pulse.
Zum Abschluss kommt ein 2.5ms Puls. Das Paket kommt dann 11x nacheinander aber jedes mit einen anderen Inhalt.
Könnte schon passen mit dem Rolling  Code.
Kann man ganz gut mit dem AUREL AM8SF empfangen.
Auf der drehenden Platine ist vermutlich ein ATTiny 841 drauf.

[herrmannj]

Herzlich willkommen !

und Danke für die Recherche.

Nehmen die echt den cc1101 für AM ? Strange. Dann haben die wohl das Ding echt OEM mit eigener Firmware. Stellt sich die Frage ob sich weiterer Aufwand lohnt wenn die SODA über Standardprotokolle laufen.

In Bezug das eigene Protokoll (und nur noch aus akademischen Interesse): Hast Du sniffs davon?

Idealerweise so: Griff resetten und das anlernen an der Zentrale aufzeichnen. Ich verstehe das sich die Nachrichten, auch in den Wiederholungen, ändern. Frage ist ob sich die Nachrichten *aus gleichem Ausganszustand (reset)* reproduzieren lassen.

vg
joerg

[pm100]

So sieht das Sendesignal aus.
Erst das ganze Paket, dann immer mehr ins Detail gezoomt.
Trigger war der erste 5ms Impuls dann zeichnet der Oszi auf.
Senden tut er bei Betätigung, ca. 20 Sekunden dann nochmal.
Ansonsten sendet der Griff ein mal pro Stunde ein Paket.

[herrmannj]

ist das ein machester code ?

vg
joerg

[herrmannj]

Hallo in die Runde,

ich habe ein aktuelles ebay Angebot (272457619595) genutzt und die Griffe bestellt und gestern erhalten.

Optisch und von der Haptik finde ich die Griffe gelungen.

Die Frage der Anbindung in fhem: beim "Untersuchen" ist mir folgendes aufgefallen. Auf dem Bild von fathbrother (https://forum.fhem.de/index.php/topic,63708.msg564148.html#msg564148)  Bild #1 sieht man oben links 8 Kontakte. Diese sind bei geschossenem Gehäuse zugänglich und ich gehe davon aus dass es sich um die Programmierschnittstelle handelt.

Für mich stellt sich die Frage ob es nicht effizienter wäre anstelle des ungewissen Versuches das verwendete Protokoll reverse engeneerieren zu wollen gleich eine Alternative Firmware zu entwickeln.

Die verwendete Hardware scheint mir wenig exotisch: der Funkchip ist cc1101 (868MHz) die CPU ist eine Atmel SAM D20. Bei den Peripherals würde ich jetzt auch keine Überraschungen erwarten. Bekannt sind 2 LEDs, 2Taster und der Buzzer. Dazu kommt der Abnehmer für den Drehgriff und der/die Alarmgeber (scheinbar Erschütterungs-Sensoren).

Über eine alternativ Firmware könnte man evtl die askin Bibliotheken nutzen. Dann wäre auch gdirekt das Problem des notwendigen weiteren Empfängers vom Tisch und es wäre evtl gleich mögl weitere Funktionen (Alarm deaktivieren, scharf/unscharf per Funkt etc) nach zu rüsten.

Frage: gibt es interessierte Mitstreiter ? Insbesondere jemand mit MCU Know How ? (In diesem Fall würde ich einen Griff zum Experimentieren zur leihweise zur Verfügung stellen). Ich bin keine Spezi dafür, zum Beispiel ist mir unklar welches Programmiergerät man benötigt.

vg
joerg

[herrmannj]

Da gibt es einiges zu lernen !

Flashen kann man die wohl per SWD, da scheint die halbe Welt den Segger J-Link zu verwenden. Von dem gibt es eine Version für den ambitionierten Hobbykoch: https://www.antratek.de/j-link-edu. Erschwinglich. Hat jemand diesen oder einen anderen geeigneten Programmer liegen ?

Des weiteren hat Atmel scheinbar eine ganze Serie bootloader (UART, SPI, Flash/SD) im Angebot. Das wirft die Frage auf ob Herr oder Frau Schellenberger freundlicherweise den UART bootloader installiert haben. Das würde das weitere Vorgehen erfreulich vereinfachen.

Um dieses Rätsel zu lösen werde ich mir noch einen Alarmgriff bestellen (müssen) und dann mal die Leitungen zum vermeintlichen update Port verfolgen. Was ich ad-hoc nicht verstehe: für SWD, UART oder SPI (eher unwarscheinlich) bräuchte man keine 8 Leitungen. Die kommen alle mit 2 Leitungen aus. Plus Spannung, einem pin um den Bootloader zu aktivieren und reset wäre man bei 6. 8 Leitungen passen erstaunlich gut zu einer SD Karte. hmmmm ....

vg
joerg

edit
na gut, eine sd karte hat 9. SPI könnte doch passen SS, MOSI, MISO, CLK, VSS, GND, BOOT, RST. 
Ist es gebräuchlich die fw per SPI drauf-zu-schieben ? (Von den dev boards mit arduino und esp mal abgesehen).

[Prof. Dr. Peter Henning]

Hat sich da jetzt etwas Neues getan ?

LG

pah

[herrmannj]

nein, leider noch nicht wirklich obwohl ich weiterhin sehr an einer Integration interessiert bin.

In der Hauptsache weil a:Zeitmangel, b:keine zündende Idee zum Vorgehen.

Ich habe das zum Anlass genommen nochmal den rf zu sniffen (Anhang). Zu sehen sind 3 Pakete aus dem gleichen Vorgang (schliessen). Dabei fallen mir auf
- obwohl es sich eigentlich nur um Wiederholungen des Kommandos handelt, die Inhalte und auch die Gesamtlänge unterscheiden sich.
  - Der Start, etwa 1/3 ist jeweils identisch. Am Anfang 15 SyncPulse, danach ein gemeinsames Muster (Startwort oder Adresse des Griffes ?)
  - Danach veränderlicher payload, scheinbar trotz gleichem "Inhalt"

Ich verstehe auch insgesamt noch nicht *wie* die (rf) kodieren. OOK ist klar, Manchester ist es nicht. Obwohl sich die Länge der rf Telegramme unterscheiden, bleiben mögliche Flanken über die Länge synchron. Spricht für mich gegen einen Kodierung über die Länge des Pulses. Also aber eher noch "Nebel".

Ich frage mich auch ob der Angang insgesamt Erfolg versprechend ist. Selbst wenn die Art der Kodierung auf rf erkannt ist: wenn "die" rolling codes korrekt umgesetzt haben würde man mit dem Wissen dann wenig anfangen können, ohne den genauen Algorithmus und den Initialisierungsvektor zu kennen. Anfänglich habe ich ja gesagt, "naja, mal schauen was die da gestrickt haben". Mittlerweile habe ich jedoch gelernt, dass Schellenberg seit Jahren Garagenöffner produziert - von daher traue ich denen schon zu dass sie das korrekt umgesetzt haben.

Den Initialisierungsvektor würde man bekommen wenn sie vergessen haben die fuse bits richtig zu setzen. Damit wären wir aber auch schon direkt beim "Plan B" den ich eh als vollständiger empfinde: die Firmware komplett zu ersetzen. CPU (SAM D20) und RF (CC1101) sind bekannt, die Stellung des Griffes wird von den GPIO kommen (Hypothese). Um den oder die Sensoren müsste man sich noch mal kümmern. Eine neue FW hätte den charmanten Vorteil das man sich auch spezielle Empfänger auf fhem Seite schenken könnte wenn man das als HM implementiert. Dazu könnte kommen: Scharf/Unscharf per fhem, stiller Alarm, Buzzer deaktivieren wenn ausgelöst etc.

Das Schreiben des Codes ist bestimmt kein Selbstläufer, aber imho zu bewältigen (da ist ja thematisch kein unbekanntes Land, wenn man vom Typ der CPU absieht. Das ASKIN Projekt existiert für den HM Part, die GPIOs sollten auch kein Hexenwerk sein, deep sleep etc - ist halt Fleißarbeit).

Wie die FW dann drauf kommt, das sei noch zu klären. Hatte immer gehofft das sich ein MCU Spezi, evtl mit Erfahrung SAM D20, beratend in diesem fred meldet, da hänge ich.

Wollen wir ein Gemeinschaftsprojekt daraus machen ?

vg
Joerg

[Prof. Dr. Peter Henning]

Ich habe gerade meinen 20 Jahre alten Garagentorantrieb durch einen neuen von Schellenberg ersetzt. Ist via 1-Wire und HM prima in mein FHEM eingebunden - aber die beigelegte Funkfernsteuerung gibt es eben auch noch.

Zur unterschiedlichen Codierung bei gleichem Inhalt kann ich jedenfalls etwas sagen: Es wird hier ein Rolling Code verwendet, ich habe nirgendwo einen genaueren Hinweis gefunden. Das macht es etwas schwierig, das Zeug zu decodieren...

Die Idee, die Firmware zu ersetzen, ist sicher brauchbar. Allerdings ist die Anzahl der Interessenten vermutlich nicht so groß - womit sich die Frage stellt, ob man nicht mit ein wenig zusätzlicher Hardware (HM-Modul parallel ?) für die wenigen Einzelfälle effizienter arbeitet.

LG

pah

[herrmannj]

Interessanter Gedanke (mit dem HM Modul). Wie würdest Du Dir das vorstellen ? Das Innenleben komplett raus, Anschlüsse raus führen und an einen HM-MOD-EM-8Bit? Oder den einbauen (wenn das geht).

Das mit der Anzahl der Interessenten steht bei mir insofern hinten an als das ich das ja primär zuerst für mich mache. Wenn sich andere später davon profitieren freut mich das - das wäre aber sekundär. Frage eher: realistisch umsetzbar ? Da helfen viele Hände natürlich.

Schau mal hier: http://www.soda-gmbh.de/alarmgriff-mit-funk/ . Evtl hilft das irgendwie. Der Griff wurde (wohl) nicht von Schellenberg entwickelt sondern von der soda. Die FW Schellenberg ist dann entweder Eigenentwicklung oder Auftragsarbeit.

Des weiteren: https://de.paulmann.com/ueber-uns/presse/pressemitteilungen/smart-friends-smart-home-aus-markenhand
Schellenberg  kooperiert bei der Funkübertragung mit (ua Abus, Paulmann) und hat "einen gemeinsamen Standard" entwickelt. Was also zumindest bedeutet das die Initialisierungen des Rolling codes über die Hersteller geshared sein muss. Ich erwähne das weil ja beim somfy der Schlüssel aus einer FW extrahiert wurde und sich damit die "Basis" wo der herkommen könnte vergrößert.  Ist aber alles mit "wenn und aber".

Die unterschiedlichen Inhalte wg Rolling code sind mit klar. Was mich wundert ist das auch für die Wiederholungen des Telegramms ein neuer Code erzeugt wird.

Mehr wundert mich aber warum die Länge des Telegramms unterschiedlich ist. Wie setzt man einen rolling code so um das sich bei gleichen Nutzdaten die Länge der verschlüsselten Nachricht ändert ? Hast Du da einen Idee ? Oder ist es die rf Kodierung die das verursacht ?

Vielleicht kommt man so dem Protocoll näher ...

evtl frag ich mal bei den MC Jungs an ob jemand den Atmel SAM D20 gut kennt und mir als Mentor erklärt wie man a: die FW auslesen könnte und b: 'ne neue drauf bekommt. Mir scheint nach wie vor da der Weg zu liegen wo sich die Risiken am besten kalkulieren lassen.

vg
joerg

edit: MCU korrigiert -> ATMEL SAM D20

[herrmannj]

Ich habe bei der SODA GmbH angerufen und mit einem sehr kompetenten, freundlichen und aufgeschlossenem Mitarbeiter gesprochen. (Er kannte sogar fhem und war sich bewusst das die Enocean Variante bereits eingebunden ist).

Folgende Erkenntnis:
- wie vermutet, zu der Schellenberg Implementierung kann und darf er keine Auskunft geben.

Allerdings denkt man (gerade im Augenblick) konkret über eine Homematic Variante nach. Das wird in Kürze entschieden und, wenn positiv, das Problem erledigt. Nachteil: Neukauf, Crossgrade wird nicht funktionieren. (Dann landen meine "alten" wohl in der Bucht )

Unter dem Gesichtspunkt wäre ich persönlich geneigt abzuwarten und meine Zeit bis dahin in andere Projekte zu investieren. Was denkst Du ?

vg
joerg

[Prof. Dr. Peter Henning]

Würde ich auch so sehen.

LG

pah

[ToSchu]

Hallo,

es gibt wohl einen USB Stick für Schellenberg Produkte, jedoch füe Quivicon Smart home Systeme.

https://www.amazon.de/Schellenberg-21009-Funk-Stick-Steuerung-Funk-Produkten/dp/B0784NSF6S/ref=sr_1_cc_5?s=aps&ie=UTF8&qid=1515665223&sr=1-5-catcorr&keywords=funk+gurtwickler

Gruß,

Tobias

[herrmannj]

Hallo,

es gibt wohl einen USB Stick für Schellenberg Produkte, jedoch füe Quivicon Smart home Systeme.

https://www.amazon.de/Schellenberg-21009-Funk-Stick-Steuerung-Funk-Produkten/dp/B0784NSF6S/ref=sr_1_cc_5?s=aps&ie=UTF8&qid=1515665223&sr=1-5-catcorr&keywords=funk+gurtwickler

Gruß,

Tobias

Vorsicht. zitat:

kompatible Schellenberg Funk-Produkte: ROLLODRIVE 65 PREMIUM und ROLLODRIVE 75 PREMIUM
geeignet für die QIVICON Home Base 1.0, QIVICON Home Base 2.0 sowie Telekom Speedport Smart
einfach in vorgesehenen USB-Steckplatz der Smart Home Zentrale einstecken

Ob der bei den Fenstergriffen funktioniert ist damit eher unsicher. Aufgeführt sind sie nicht. Außerdem ist der rf nur die halbe Miete, die rolling codes müssen abgearbeitet werden. RF technisch braucht man nur einen cc1101, einem cul reicht da. Dann kan man das zwar (mechanisch) lesen aber die Bedeutung der Nachrichten ist verschlüsselt.

Einfach erklärt: Du siehst das die Griffe ein "kdbgrkdbkv" senden (fiktiv) kannst aber nicht erkennen was sie Dir damit sagen wollen. Die gleiche Nachricht sieht bei der nächsten Übertragung dann (fitkiv) so aus "ishgiishdflkb" usw

[ToSchu]

Vorsicht. zitat:Ob der bei den Fenstergriffen funktioniert ist damit eher unsicher. Aufgeführt sind sie nicht. Außerdem ist der rf nur die halbe Miete, die rolling codes müssen abgearbeitet werden. RF technisch braucht man nur einen cc1101, einem cul reicht da. Dann kan man das zwar (mechanisch) lesen aber die Bedeutung der Nachrichten ist verschlüsselt.

Einfach erklärt: Du siehst das die Griffe ein "kdbgrkdbkv" senden (fiktiv) kannst aber nicht erkennen was sie Dir damit sagen wollen. Die gleiche Nachricht sieht bei der nächsten Übertragung dann (fitkiv) so aus "ishgiishdflkb" usw

Hi,

ich wollte eigentlich nur auf eine Diskussion weiter vorne im Thread reagieren, in der die Frage nach einem USB Stick zur Steuerung von Gurtwicklern auf kam. Kann aber auch sein, das ich das falsch verstanden habe.

Gruß,

Tobias

Gesendet von meinem SM-G935F mit Tapatalk

[herrmannj]

nö, alles gut. Ich hab das fälschlicherweise dann auf die Griffe von oben bezogen. Passt alles

vg
Joerg