Gira Dual Rauchmelder, Vernetzung - Einzelauswertung - Fernauslösung

[makki]

Jep, richtig, ich habe kein Funkmodul und will auch eigentlich keins, da ich ggfs. Strippen hätte
Wie ich wohlwollend sehe wird das aber langsam ja auch

IMHO: Auf dem Pfostenstecker liegt das Zeug, ich würde fast was wetten, das das Funkmodul und der zugehörige Diagnose-USB-Stecker nur eine serielle "Bridge" ist, allerschlimmstenfalls könnte man sich z.B. hier bedienen um das für kleines Geld "on-air" zu bekommen aber ich muss erstmal alle montieren, bevor mehr Zeit für basteleien bleibt
Als "Notfall-Lösung" bliebe noch Funkmodul + USB-Adapter an den Linux-Hobel: als was meldet sich das Ding denn? (Win/Gerätemanager oder lsusb -v: V[endor]ID/PID)

Noch ein Crosslink, damit wir nichts verpassen

Makki

[jaykay]

Hier die Projektdatei. Kannst Du mir dein Python Script mal zukommen lassen? Vielleicht kann man das auch für das DiagnoseTool nutzen. Dann haben wir nicht x verschiedene...

[netsrac]

Bin gerade mal ein bischen am Brainstormen:

Wie kann man eigentlich die Kommunikation auf dem USB port abhören. Das letzte Mal, dass ich sowas gemacht habe waren es noch "normale" serielle Schnittstellen :-)

Wenn ich den einen Rechner über USB mit dem Gira Tool verbinde. Kann ich dann einfach einen zweiten USB Anschluss nehmen (sozusagen ein Y-Kabel) und dann mit einem zweiten Rechner den Funkverkehr abhören?!

Ich weiß, ein bischen off-topic, aber vielleicht hat hier ja jemand eine schnelle Lösung.

Gruß, Netsrac

[mode]

@Makki,
leider sind die Funkmodule nicht nur eine Bridge. Sie übernehmen auch die komplette Adressierung. Einfach mehrere RM an einen RS485 Bus ist also nicht.
Da die RM aber nur in sehr seltenen Fällen von sich aus senden, sind Kollisionen sehr unwahrscheinlich. Um jetzt einen bestimmten RM anspechen zu können, müsste die Adressierung nachgebaut werden. Zb. mit einem kleinen uC vor dem RX Eingang des RMs, der die Daten nur weiterleitet wenn er durch ein zu diesem RM passendens Magic Paket dazu aufgefordert wurde.
So eine kleine Platine mit einem AT-Tiny und einem 485 Treiber könnte anstatt dem Funkmodul eingebaut werden und würde < 10€ in Eigenfertigung kosten. Ggfs bekommen wir ja sogar noch eine galv. Trennung zwischen RM und 485 Bus hin.

Das Gira Funkmodul emuliert nur einen COM Port. Die Gria Software sucht alle verfügbaren COM Ports ab. Läuft sogar auf einem nativen COM Port (ja sowas habe ich noch) :-)

@JayKay
Ich werde diese Woche meine Exceltabelle und Pythonscripte dokumentieren und hier hochladen.
Es sollen 2 Scipte werden. Eins spricht mit der Gira Software und simuliert einen RM.
Das andere spicht mit dem RM und simuliert einen kleinen Teil der Gira Software (einfach ein paar Werte auslesen, umrechnen und anzeigen).

Die Scripte sind an sich sehr ähnlich. Sie warten auf einen bestimmten String, und antworten dann mit einem String.
Bzw. senden einen String und holen die Antwort ab.
Die Strings sind in einem 2 Dim Array ableget und können schnell erweitert werden.

Danke für die Projektdatei - werde ich heute Abend Testen...

@netsrac
Da die USB Verbindung einfach nur eine serielle Verbindung emuliert, kannst du die Daten, wie JayKay es bereits gemacht hat, einfach hinter dem USB/Serial Chip (FTDI??) abgreifen.

Mode

[netsrac]

Kurze Frage, welche Kommunikationseinstellungen habe Ihr für den seriellen Port gesetzt?

9600 Baud, 8n1

?

[mode]

Ja...

[netsrac]

0003: 12345678
         Betriebszeit in Sekunden = "12345678" / 4

0004: 12345678
         Rauchkammerwert = "1234" * 0,003223
         Anzahl Rauchalarm = "56"
         Verschmutzungsgrad = "78"

0005: 12345678
         Batteriespannung = "1234" * 0,018369
         Temperatur von Messfühler 1 = "56" / 2 - 20
         Temperatur von Messfühler 2 = "78" / 2 - 20

0006: 12345678
         Anzahl Thermoalarm = "12"
         Anzahl Testalarm = "34"
         Anzahl Alarm Draht = "56"
         Anzahl Alarm Funk = "78"

0007: 12345678
         Anzahl Testalarm Draht = "56"
         Anzahl Testalarm Funk = "78"

0064: 12345678
         "78" wird Bitweise ausgewertet
         Bit 1: Gruppenadresse True/False
         Bit 4: Kompatibel True/False
         Bit 8: Repeater True/False

Batteriespannung = ankommenderWert * 5.7 * 0.00322265625;

Die zaheln zwischen <STX> und : geben bestimmte Sachen an:

0002: Betriebszeit oder so
0003: Rauchkammerwert, Anzahl_Rauchalarm, Verschmutzungswert
0004: Batteriespannung, Temp1, Temp2
0005: Anzahl_Termoalarm, Anzahl_Testalarm, Anzahl_Alarm_Draht, Anzahl_Alarm_Funk
0006: Anzahl_Testalarm_Draht, Anzahl_Testalarm_Funk
0007: Gruppenadresse, Kompatibel, Repeater

Ich versuch da noch weiter dran rum ...

Sind wir uns denn nun eigentlich mit den Daten sicher? Habe mal durch den thread geschaut und es gibt ja unterschiede zwischen den Daten von panzaeron, Daviid und von JayKay...

[mode]

Die Angaben von panzaeron ergeben bei mir plausible Ergebinisse; bis auf 0007. Hier werden nur 4 Bit übertragen. Aber das laesst sich leicht umdenken ;-)

[daviid]

Hab grad nochmal geschaut, die Daten von panzaeron stimmen.
Aber auch meine wenn man auf die Codes vorne noch 1 aufaddiert, dann hat man wieder das von panareron.

Im RWM-Tool wird 0001 auf case 0 umgelegt, hatte mich da vertan.

[jaykay]

@Makki: Hier die Kernel Meldungen aus /var/log/messages bzw. lsusb -d 0403:6001
Dec 21 20:16:27 kernel: [3366347.665690] usb 1-2.1.3: new full speed USB device using uhci_hcd and address 124
Dec 21 20:16:28 kernel: [3366347.824842] usb 1-2.1.3: configuration #1 chosen from 1 choice
Dec 21 20:16:28 kernel: [3366347.850701] ftdi_sio 1-2.1.3:1.0: FTDI USB Serial Device converter detected
Dec 21 20:16:28 kernel: [3366347.850747] ftdi_sio: Detected FT232RL
Dec 21 20:16:28 kernel: [3366347.850822] usb 1-2.1.3: FTDI USB Serial Device converter now attached to ttyUSB1
Dec 21 20:16:28 kernel: [3366347.856852] usb 1-2.1.3: New USB device found, idVendor=0403, idProduct=6001
Dec 21 20:16:28 kernel: [3366347.856852] usb 1-2.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Dec 21 20:16:28 kernel: [3366347.856852] usb 1-2.1.3: Product: FT232R USB UART
Dec 21 20:16:28 kernel: [3366347.856852] usb 1-2.1.3: Manufacturer: FTDI
Dec 21 20:16:28 kernel: [3366347.856852] usb 1-2.1.3: SerialNumber: xxxxx


lsusb -d 0403:6001
Bus 001 Device 124: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC


Ich könnte mir auch vorstellen die RM mit einem FreeBus Modul direkt auf den Bus zubringen. Ein LPC2TE sollte locker in den Modul Steckplatz hineinpassen. Und mit einem DC/DC Wandler und einem ADUM 1201 AR sollte man das gut vom Bus isolieren können. Keine Ahnung was die Platine kosten würde, aber die Bauteile sind auch bei ca. 10 €. Die Sourcen scheinen bei Freebus jetzt auch offen im Git zuliegen (lesend für registrierte User)... Das wäre, finde ich die, sauberste aber auch aufwändigste Lösung ;-) Und macht nur sind wenn man Mitstreiter findet....

[mode]

Weiterer Erfolg, ich konnte soeben mit meinem Script erfolgreich einen RM mit Funkmodul emulieren; Die Girasoftware zeigt ihn an :-) . Die Logs von JayKay sind Gold wert! Danke dafür!!!

PS: LPC ist bah ;-)

[makki]

@Makki,
leider sind die Funkmodule nicht nur eine Bridge. ...

Na und, davon lassen wir uns doch nun nicht abschrecken, LPC wär nun auch nicht so meins aber wie genau ist mir ehrlichgesagt sekundär, wenns denn geht, hätte ich die Mittel und den Willen es auch mal "einzurreichen"
Es steht Gira ja frei, endlich ein KNX-Modul dafür zu bringen aber bis dahin müssen wir uns halt anders helfen

Makki

[mode]

Welchen weg würdest du gehen:
A) Jeder Rauchmelder wird ein KNX Node und hängt direkt am KNX Bus.
B) Die Rauchmelder kommunizieren über einen eigenen RS485 Bus und es gibt einen zentralen Konverter zu KNX.

[jaykay]

Ich fände 1. gut da man dann über EIB (rt/sw) die Diagnosedaten und Spannungsversorgung hätte und über (gl/ws) die Vernetztung der RM beibehalten könnte. Somit laufen wir nicht Gefahr die Funktion der RM zu beeinträchtigen.

Der LPC hat nur den Vorteil das es bei FreeBus schon fertige SW / Libs gibt und man die RM ggf. per ETS programmieren könnte.... Also für die normalen User alles wie gehabt. Dann kommen wir bei einer Sammelbestellug vielleicht auf höhere Stückzahlen.
Wobei ich auch für andere EIB Lösungen offen bin. Habe nur noch nichts gefunden was in Grösse, Preis etc. paßt.

Wenn Gira endlich auf den Zug aufspringen würde, wäre das natürlich charmanter.....

[JaKop]

Es steht Gira ja frei, endlich ein KNX-Modul dafür zu bringen aber bis dahin müssen wir uns halt anders helfen

ich könnt mir vorstellen, dass irgend ein Ingenieur von Gira hier mitliest und ein Brennen in den Fingern hat zu schreiben, wie das Protokoll wirkich aussieht, aber ihm ein Projekt-Marketingmanager mit dem schlimmsten droht
Aber was könnte besseres Marketing sein als wenn Gira sagen würde "unter Verlust von Gewährleistung, VDS, VDE, BSE, HIV, Unschuld und was man sonst noch alles verlieren kann, schaut mal hier..."