Schellenberg Smart Home Zentrale SH1 in FHEM einbinden

[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