IButton HomeMatic Türöffner/Schlüsselbrett HB-IBUT-8

[ext23]

Ich möchte hier mein iButton Schlüsselbrett vorstellen. Das Schlüsselbrett verrichtet schon seit einigen Jahren erfolgreich seinen Dienst. Es wird jedoch zunehmend immer schwieriger die iButtons über das normale OWX Modul am 1-Wire Bus abzufragen. Das Problem ist, dass diese iButtons ständig gepollt werden müssen (<5s) um sinnvoll die Funktion eines digitalen Schlüsselhalters zu realisieren. Auch ist diese Variante sehr störanfällig. In dem AskSin++ Thread (https://forum.fhem.de/index.php/topic,57486.msg844810.html#msg844810) kam dann die Idee auf, dafür ein HB HM Device zu kreieren. Eigentlich wollte -papa- nur ein iButton Türöffner haben und da habe ich mich mit meinem Use-Case zwischen gedrängelt und siehe da, das Gerät "HB-IBUT-8" (https://github.com/pa-pa/AskSinPP/tree/master/examples/custom/HB-IBUT-8) ist entstanden.

Aufbau meines Schlüsselhalters:
Ich habe 3 iButton Magnetkontaktflächen (Ich meine die waren aus dem fuchs-shop) verbunden zu einem 1-Wire Bus. Für das HB-IBUT-8 als Hardware verwende ich einen alten AVR panStamp (https://wiki.fhem.de/wiki/PanStamp). Man kann hier natürlich auch ein AVR/Arduino zusammen mit dem CC1101 Funkmodul nehmen oder auch was anderes.
In meinem Schlüsselbrett befindet sich noch ein LCD mit 1-Wire Adapter (https://wiki.fhem.de/wiki/1-Wire_Textdisplay) welches aber an meinem regulären 1-Wire Bus hängt und über OWX angesprochen wird. Das steuert im übrigen auch die LEDs in den Magnethaltern.

Platine und Verkabelung:
Die Platine habe ich auf Lochraster schnell zusammen gelötet. Durch Verwendung des panStamps wird hier nicht viel benötigt. Man braucht nur irgendwie die 3,3V für das Modul und die iButtons (Die iButtons laufen sauber mit 3,3V, hat man ein 5V Modul (Arduino nano) geht das natürlich auch! Aber das CC1101 braucht glaube ich eh 3,3V, macht also kein Sinn 5V zu benutzen.). Dann sollte man sich 2 Taster für config und reset (optional) genehmigen und entweder eine Dual oder zwei einzelne LEDs für die klassischen HM Status. Der Grundaufbau ist also für alle HB HM Geräte gleich. Für die iButtons und dem 1-Wire Bus gibt es aber eine Besonderheit. Die iButtons haben nur 2 Kontakte und werden aus diesem Grund parasitär mit Strom versorgt. Aus diesem Grund ist es wichtig den 1-Wire Bus auf ein High Pegel zu halten. Die Kondensatoren in den iButtons speichern somit genug Energie um die Übertragung der Seriennummer zu gewährleisten. Den 1-Wire Bus hält man mit Hilfe eines 4,7 kOhm Widerstandes gegen VCC auf High Pegel. Zu gering sollte der Widerstand nicht sein, da sonst eine Kommunikation nicht mehr möglich ist. Der Pegel muss ja zum Senden auch irgend wann mal auf Low gehen können. Viel mehr als 4,7 kOhm sind auch nicht gut, dann kann es wiederum Probleme bei der Kommunikation geben. Was also annähernd 4,7 kOhm hat und in der Schublade liegt ist zu gebrauchen.

Funktion:
Für das Schlüsselbrett können "beliebig" viele iButton Kontaktflächen zu einem 1-Wire Bus zusammengefasst werden und mit dem HB-IBUT-8 verbunden werden. Zuerst muss das neue Gerät natürlich mit einer CCU/FHEM etc. gepaired werden. Das Gerät stellt 8 Kanäle zu Verfügung. Jedem Kanal kann ein iButton bzw. eine iButton Seriennummer zugewiesen werden. Das kann auf 2 Wegen geschehen. Entweder man schaltet einen Kanal auf "on" und hält anschließend den neuen iButton auf eine freie Kontaktfläche, oder man fügt über die Register R-addressHi und R-addressLo die Adresse manuell hinzu.

Standardmäßig verhält sich das Gerät wie eine Fernbedienung. Es werden Remote-Events (Short/Long) gesendet, wenn ein bekannter iButton erkannt wird. Wird das buttonMode Register von remote auf state umgestellt, verhält sich das Gerät, wie ein ThreeStateDevice (z.B. Fensterkontakt) mit den States [absent,present,educate].

Das funktioniert wirklich sehr schnell und sauber. Man spart sich also das ganze polling. Ich bin wirklich sehr zufrieden. Einziger Wermutstropfen ist die ungesicherte Übertragung über Funk. Da aber nicht die Seriennummer an sich übermittelt wird ist es halb so schlimm. Ein Außenstehender muss also schon ziemlich genau wissen, was dieses HM Gerät macht. Der Gedanke ist deshalb wichtig weil man natürlich seine Alarmanlage darüber steuern kann.

FHEM seitig kann man hier natürlich entsprechend reagieren und je nach Gusto beim Verlassen der Wohnung die Heizung und das Licht abstellen etc. Das ist dann aber ein anders Thema.

Die Magnethalter sind übrigens sehr gut, da ist noch nie ein Schlüsselbund abgefallen. Es kann nur mal passieren, dass es kein Kontakt gibt. Beim Anhängen des Schlüssels macht es sich also gut eine kleine gekonnte Drehung auszuüben um den Dreck weg zu schleifen. Ein kleiner Nachteil ist (je nach System), dass der iButton magnetisch ist und nicht der Halter. Sprich in der Tasche aufpassen mit Kreditkarten und es sammeln sich im Laufe der Zeit auch Eisenspäne an dem Ding. Ein "klebenbleiben" am Schlüsselring wie einige berichten etc. stört mich eigentlich weniger.

Die Software bzw. Firmware kann man gut selber kompilieren mit der Arduino IDE. Man muss natürlich die HM Seriennummer und die Ports für die Taster, LED und vor allem den 1-Wire Bus anpassen! Beispiel:

Code Auswählen Erweitern

#define LED1_PIN 4 //rot
#define LED2_PIN 5 //gelb
#define CONFIG_BUTTON_PIN 9
#define IBUTTON_READER_PIN 8

Damit FHEM mit dem Gerät etwas anfangen kann, muss das aktuelle HMConfig_AskSinPPCustom.pm installiert werden - in das FHEM Verzeichnis kopiert werden.

Da mein Schlüsselbrett schon ein paar Tage alt ist gibt es hier im Forum bereits Fotos aber ich hänge noch mal aktuelle Bilder an diesen Thread.

Verbesserungen:
- Steuerung der LEDs in den iButton Magnetkontaktflächen über das HB-IBUT-8 Gerät
- Eventuell mehr als einen 1-Wire Bus auf dem HB-IBUT-8 bereitstellen. Der Vorteil wäre hier das man erkennt auf welchem der Kontaktflächen welcher iButton hängt. So kann man dann auch die LEDs individuell steuern.

Bei Fragen einfach melden! Ein Dank geht natürlich an papa für die Erstellung/Programmierung des neuen HB-IBUT-8!

/Daniel

[papa]

Danke für die ausführliche Dokumentation. Von mir noch schnell zwei Anmerkungen:

• Damit FHEM mit dem Gerät etwas anfangen kann, muss das aktuelle HMConfig_AskSinPPCustom.pm installiert werden - in das FHEM Verzeichnis kopiert werden.
• Standardmäßig verhält sich das Gerät wie eine Fernbedienung. Es werden Remote-Events (Short/Long) gesendet, wenn ein bekannter iButton erkannt wird. Wird das buttonMode Register von remote auf state umgestellt, verhält sich das Gerät, wie ein ThreeStateDevice (.z.B Fensterkontakt) mit den States [absent,present,educate].

[eppi]

Danke vielmals für die ausführliche Anleitung!
Ich habe noch eine Frage. Beim komplilieren kommt eine Fehlermeldung

Code Auswählen Erweitern

'DREG_BUTTON_MODE' was not declared in this scope

Laut dieser Fehlermeldung muss da der ButtonMode deklariert werden. Wie und wo mache ich das?
Danke vielmals und viele Grüsse eppi

[ext23]

Hast du die letzte AskSin Version etc? Da braucht man nichts deklarieren.

/Daniel

[eppi]

Hast du die letzte AskSin Version etc? Da braucht man nichts deklarieren.

Genau, das wars - Danke für den Tip. Weiter gehts...

[Prof. Dr. Peter Henning]

Prima, danke für die Beschreibung.

Ich habe schon länger einen Garagentoröffner, in dem ein Arduino alle 250 ms den iButton-Leser pollt. Und als externe Ansteuerung dazu einen HM-LC-SW1-BA-PCB
Und in der Pipeline eine modifizierte Version, bei der auch noch zwei Neigungssenssoren angeschlossen sind. Das kann ich mit dem Beispiel jetzt alles in einem realisieren.

Gibt es irgendwo eine Beschreibung zur Anbindung des  CC1101 an einen Arduino?

Hat jemand ein Beispiel mit der AskSinPP++ schon auf einem EspDuino oder einem anderen der fetten 5V-Arduinos zum Laufen bekommen ?

LG

pah

[papa]

Gibt es irgendwo eine Beschreibung zur Anbindung des  CC1101 an einen Arduino?

Am besten hier bei Jerome, da gibt es jede Menge Bauanleitungen - https://github.com/jp112sdl/Beispiel_AskSinPP

Hat jemand ein Beispiel mit der AskSinPP++ schon auf einem EspDuino zum Laufen bekommen ?

Nein, wenn das aber halbweg ordentlich kompatibel ist und die Standard-Libraries gehen, sollte es nicht so schwer sein. Für ein Basisgerät reicht ein Timer, I2C für die EEPROM-Anbindung und SPI-Library für die CC1101-Anbindung.

[eppi]

Hallo zusammen
Ich habe heute morgen erfolgreich meinen ersten iButton angelernt und es funktioniert nach einigem try & error super. Nochmals ein herzliches Dankeschön für die tolle Anleitung und die Software.

Eine Anmerkung habe ich noch:

Jetzt muss man sich entscheiden für welchen Anwendungsfall man das HB-IBUT-8 verwenden möchte. Für das Schlüsselbrett muss der buttonMode auf state gesetzt werden (set DEVICE buttonMode state). In diesem Fall wird beim Anstecken und Abziehen jeweils ein event gesendet.

Um den ButtonMode umzustellen auf state, muss der Befehl wie folgt aussehen:

Code Auswählen Erweitern

set <Device> regSet buttonMode state
Also regSet nicht vergessen....

Viele Grüsse eppi

[ext23]

Ich hab das oben mal angepasst, danke.

[eppi]

Eine Frage habe ich noch:
Mein Device hat folgende Attribute:

Code Auswählen Erweitern

model HB-IBUT-8
subType custom
Mit dem "subTyp custom" ist gibt mir der state bei aufgelegtem iButton ein "present" aus, bei nicht aufgelegtem iButton ein "absent". Da gefällt mir, jedoch schreibt mir der iButton bei jedem Event ein Log-Eintrag mit:

Code Auswählen Erweitern

HB-IBUT-801 is threeStateSensor
ins Log. Wenn ich den subTyp ändere auf threeStateSensor, dann habe ich keinen Logeintrag (wie  ich es gerne möchte), jedoch ist dann der state bei aufgelegten iButton "tilted" und bei nicht aufgelegten iBUtton "closed", was suboptimal ist. Jetzt könnte ich das zwar anpassen mit eventMap, möchte aber fragen, ob es eine andere Möglichkeit gibt?

Besten Dank!

[papa]

Das ist noch mein Debug-Code. Du kannst einfach Zeile 164 in HMConfig_AskSinPPCustom.pm auskommentieren. Ich will/muss das noch auf eine andere Logging-Funktion umstellen. Siehe auch https://github.com/pa-pa/AskSinPP/issues/57
Leider fehlt mir dazu gerade die Zeit.

[eppi]

Hallo
Ich habe noch eine Frage: Muss ich für jedes Device das ich mit dem Sketch flashe eine eigene Device-ID und Serial definieren?

Code Auswählen Erweitern

// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
    {0x34,0x56,0x78},       // Device ID
    "ibuttread1",           // Device Serial
    {0xf2,0x06},            // Device Model
    0x02,                   // Firmware Version
    as::DeviceType::Sensor, // Device Type
    {0x00,0x00}             // Info Bytes
};
Wenn ja, wie generiere ich die Device-ID?

Besten Dank und viele Grüsse Eppi

[papa]

Ja - die Device-ID und die Serial müssen eindeutig sein.
https://github.com/jp112sdl/AskSinPPCollection/blob/master/Markdown/FAQ.md#verwendung-mehrerer-ger%C3%A4te-desselben-typs---vergabe-von-seriennummern

[eppi]

Alles klar, besten Dank für die Klärung!

[eppi]

Meine Schlüsselbretter mit den iButton's sind fertig. Ich musste aus Platzgründen und der bestehenden Verkabelung den Arduino mit dem CC1101 zentral montieren. Das bedeutet, dass ich mit dem 1Wire Bus von da aus zu den zwei Schlüsselbretter fahre. Eine Leitung ist ca 10m, die andere ca 6m lang. Dadurch musste ich den Widerstand (zwischen 3.3V und 1Wire-Data) von 4.7k auf 220 Ohm reduzieren. Damit funktioniert es einigermassen. Das Problem ist, dass ab und zu sich ein iButton abmeldet und 1sec später wieder da ist.... Ich habe schon diverse andere Widerstandswerte probiert (kleiner und grösser), aber die optimale Lösung habe ich nicht gefunden...
Hat jemand einen Tipp, wie ich das "zeitweilige flackern" der iButtons in den Griff kriege?

Danke vielmals und Grüsse eppi