Du musst die Sektion einkommentieren 
Hallo pmeyer,
danke für die schnelle Rückmeldung.
Bittere Fehlleistung meinerseits 
Ich habe jetzt das pairing versucht. Die peer id ist bei mir 22.
`sudo homegear -e rc '$hg->setValue(22, 1, "PAIRING", true);'`
Das Ergebnis sieht folgendermaßen aus:
01/03/18 08:00:42.627 Info: CLI connection accepted. Client number: 216
01/03/18 08:00:42.628 Script Engine Server: Info: Starting script "/var/lib/homegear/scripts/inline.php" with id 2.
01/03/18 08:00:42.636 Script Engine Server: Info: Client number 0 is calling RPC method: setValue Parameters:
01/03/18 08:00:42.636 Module Intertechno: Info: PAIRING of peer 22 with serial number ITD000C077F:1 was set to 0x01.
01/03/18 08:00:42.636 Module Intertechno: COC "My-COC": Info: Sending (My-COC): 00000000001100000001110111011111
01/03/18 08:00:42.640 Info: Script with id 2 finished with exit code 0
01/03/18 08:00:42.647 Info: Connection to CLI client number 216 closed.
01/03/18 08:00:43.15401/03/18 08:00:43.154 HomeMatic BidCoS packet received (My-COC Intertechno packet received from 00000000 (RSSI: -69 dBm):
, RSSI: -66 dBm): 09000000000110000000
Gefühlt sieht das besser aus. Bekomme aber noch keine Rückmeldung durch den Melder bei Bewegungen.
Vg becksen
Da bin ich leider raus, weil ich selbst kein Intertechno habe. Aber Komisch ist, das es um HomematicBidcos Pakete gehen soll während du Intertechno machen willst.
In welcher Datei hast du deinen COC eingetragen? Und ist das nicht ein 868MHz Funkmodul?
Du kannst das pairing auch über die homegear-Konsole mit sudo homegear -r machen. Gib da jeweilse mals Hilfe ein.
Danke für die Rückmeldung.
Bin mir nicht sicher ob das Log das richtig wiederspiegelt. Das Intertechno Modul wir ja erwähnt in der logs auch wenn dass wieder HomeMatic BidCos gezeigt wird.
Grundsätzlich habe ich die COC Konfiguration in beider families Dateien durchgeführt. Intertechno.conf und HomeMaticXXXX.conf.
HomeMatic läuft bereits seit Monaten stabil.
Ich habe in beiden jedoch die gleiche id verwendet und zwar: My-COC. Das werde ich ändern um herauszufinden wann die intertechno.conf denn verwendet wird.
Der Busware COC kann beides, 868 und 433 Mhz.
Das Pairing geht nur für Homematic Geräte über sudo homegear -r. Bei intertechno ist laut homegear Doku tatsächlich der command Befehl zu verwenden. Anders fände ich auch schöner, habe aber keine Möglichkeit gefunden.
1 Like
Du kannst das Modul leider nicht gleichzeit füt beide Familien verwenden. Homegear benötigt exklusiven Zugriff für Homegear um auf die Pakete die empfangen werden zu “hören”.
Es empfiehlt sich ein zweites Kommunikationsmodul für Intertechno anzuschaffen, allein schon weil die Antennenkonfigurationen bei 433 und 868MHz unterschiedlich sind.
Hallo pmayer,
das wäre schade, weil es ja beides kann. Ich habe hier folgenden Artikel gefunden der doch noch etwas Hoffnung macht. Aber Du hast recht ein zweites Funkmodul wäre wohl am einfachsten.
Der Artikel bezieht sich auf FHEM. Meines Wissens nach ist es in Homegear nicht implementiert. Da kann aber @sathya sicher was zu sagen.
Hallo @becksen,
der Parallelbetrieb mit Intertechno und HomeMatic wäre theoretisch möglich, wenn nur Intertechno-Aktoren verwendet werden. Sobald Sensoren im Einsatz sind, geht nur entweder oder. Diese Einschränkung lässt sich auch nicht umgehen.
Weiterhin unterscheiden sich zwischen 433 und 868 MHz die Baluns. D. h. ein Mischbetrieb ist zwar möglich aber absolut nicht zu empfehlen.
sudo homegear -e rc '$hg->setValue(22, 1, "PAIRING", true);'
Der Befehl ist für Aktoren, der Bewegungsmelder ist aber ein Sensor. Da muss nichts angelernt werden, das Gerät muss nur in Homegear angelernt werden. Erscheinen bei Bewegung Pakete im Homegear-Log? Hast du auf dem COC die a-culfw? Falls nicht, können Intertechno-Pakete nicht empfangen werden.
Viele Grüße
Sathya
2 Likes
Halllo @sathya,
danke für die hilfreiche Antwort.
Aktuell sehe ich keine Einträge im Homegear log wenn Bewegungen ausgelöst werden. Vermutlich läuft er auf 868 MHz.Darüber hinaus versuche ich den COC mit culfw zu bespielen jedoch ohne Erfolg. Habe unterschiedliche Anleitungen verwendet. Diese zuletzt.
Das flashen mit a-culfw funktioniert ums verrecken nicht. Immer der gleich Fehler. Diese Version versuche ich gerade zu flashen: https://github.com/heliflieger/a-culfw
This program flash the COC device with new firmware.
Please change the device into the bootloader
-------------------------------------------------------------
Please choose a device:
1 = COC
2 = COC_radio_only
Please select device (1-2): 1
Please insert the port for your device [default /dev/ttyAMA0]:
The device will now be flashed
Continue (y/n)?y
calling radio frontends bootloader ...
Call now avrdude -patmega1284p -cavr109 -P/dev/ttyAMA0 -b38400 -D -Uflash:w:./COC.hex:i
Connecting to programmer: .avrdude: butterfly_recv(): programmer is not responding
Habe auch schon andere culfw Versionen getestet. Immer das gleich Ergebnis. Scheint grundsätzlich etwas schwierig zu sein mit den COCs.
VG
becksen
Ich habe jetzt einen NanoCUL,
mit dem ich die Intertechno Pakete des PIR-1000 empfangen kann. Habe ich aber nur mit FHEM ans Laufen bekommen.
Somit weiß ich dass es funktioniert. Würde aber trotzdem lieber Homegear in Verbindung mit OpenHab2 verwenden. Wie muss ich den NanoCUL unter homegear einrichten um die Ergebnisse in einem OH Thing verwenden zu können?
Danke.
Hallo @becksen,
genauso wie den normalen CUL. Siehe https://doc.homegear.eu/data/homegear-intertechno/configuration.html#config-cul.
Viele Grüße
Sathya
Hallo zusammen,
es ist schon eine Weile her.
Bekomme jetzt die Pakete vom Intertechno Bewegungsmelder. Wie muss ich das Device denn in homegear anlegen damit es den Status 01(an) und 00 (aus) speichert und in Openhab weiterverwendet werden kann?
12/31/18 17:03:54.167 Intertechno packet received from 01574D6A (RSSI: -73 dBm): 01
Ich hatte folgendes Probiert
pc My-IT-CUL 2 01574D6A
und
pc My-IT-CUL 0x30 01574D6A
Die Änderung des Status konnte ich aber nie sehen. Was ist der beste Ansatz dafür?
Danke.
Hallo @becksen,
eigentlich müsste im Log eine Meldung wie Please use one of the following addresses for device creation ... auftauchen?
Der korrekte Typ müsste 0x10 sein. Vor der Adresse muss im pc jedoch noch ein 0x stehen. Zudem kann es sein, dass die Adresse mit 8 anfangen muss. Also: 0x01574D6A oder 0x81574D6A.
pc My-IT-CUL 0x10 0x01574D6A
Klappt es damit?
Viele Grüße
Sathya
Hallo @sathya,
danke für die Rückmeldung.
Ich hatte eben zwei peers parallel angelegt mit 0x01574D6A und 0x81574D6A. Dann meckert homegear was auch Sinn macht:
01/13/19 23:52:56.474 Please use one of the following addresses for device creation (possible device types: 0x10 to 0x1F): 0x01574D6A or 0x81574D6A
Dann habe ich jeweils einen peer gelöscht und wieder angelegt. Am Ende konnte ich über 0x01574D6A erkennen dass dort Pakete empfangen wurden:
01/13/19 23:52:57.926 Intertechno packet received from 01574D6A (RSSI: -66 dBm): 01
Über config print konnte ich mit LAST_PACKET_RECEIVED bestätigen dass etwas angekommen ist. Nur leider bewirkt das empfangene Paket mit dem Wert 00 oder 01 keine Änderung im Channel: 1 für Status. Die anderen Attribute ändern sich übrigens auch nicht egal ob für Channel1 oder Channel0, außer LAST_PACKET_RECEIVED und RSSI_DEVICE.
Ich habe beobachtet, dass LAST_PACKET_RECEIVED unterschiedliche Werte kennt: 5c 3b c4 b1, 5c 3b c4 9b, 5c 3b c6 df. Also mehr als zwei, somit kann ich damit nicht ableiten ob der Bewegungsmelder gerade aktiv ist oder nicht.
Ich würde gerne das Attribut [STATE] mappen und über die empfangenen Pakete steuern.
Family 16 - peer 12> config print
MASTER
{
}
VALUES
{
Channel: 1
{
[STATE]: 00
}
Channel: 0
{
[UNREACH]: 00
[GROUP_STATE]: 00
[LAST_PACKET_RECEIVED]: 5c 3b c1 c5
[RSSI_DEVICE]: c4
[STICKY_UNREACH]: 00
}
}
Was ist da noch falsch?
Danke
becksen
Hallo @becksen,
so, ich habe mir das jetzt noch einmal in Ruhe angesehen. Offenbar ist der Kanal falsch ausgelesen. Jetzt gibt es zwei Möglichkeiten: Im nächsten Nightly habe ich das Logging einmal verbessert, so dass auf Loglevel 5 die Rohpakete geloggt werden. Diese Ausgabe bräuchte ich einmal. Alternativ kannst du als Gerätetyp einmal 0x1F (16-Kanal-Fernbedienung) auswählen. Damit sollte es in jedem Fall gehen (du kannst damit auch bereits den PIR an OpenHAB anbinden) und der korrekte Kanal sollte im Log erscheinen. Diesen bräuchte ich einmal, dann passe ich die XML-Datei für den PIR entsprechend an.
5c 3b c4 b1 , 5c 3b c4 9b , 5c 3b c6 df
Das sind Unix-Timestamps. 0x5C3BC4B1 => 1547420849 (dezimal) => Montag, 14. Januar 2019 00:07:29
Viele Grüße
Sathya
1 Like
Das Problem sollte im nächsten Nightly behoben sein. Siehe: Integration Smartwares SH5-TSO-A (Bewegungsmelder)
Hallo @sathya,
Danke für die Rückmeldung. Ich schaue mir das nächste Woche an weil ich derzeit unterwegs. Melde mich dann.
Danke und Gruß
Hallo @sathya,
ich habe es jetzt mit 0x1F probiert. Das funktioniert tatsächlich. Der passende Kanal lautet 10.
Bezüglich des Nightly, kann ich das gefahrlos über die Stable version installieren und bei Bedarf zurückkehren?
Family 16 - peer 11> config print
MASTER
{
}
VALUES
{
Channel: 16
{
[STATE]: 00
}
Channel: 15
{
[STATE]: 00
}
Channel: 14
{
[STATE]: 00
}
Channel: 13
{
[STATE]: 00
}
Channel: 12
{
[STATE]: 00
}
Channel: 11
{
[STATE]: 00
}
Channel: 10
{
[STATE]: 01
}
Channel: 3
{
[STATE]: 00
}
Channel: 2
{
[STATE]: 00
}
Channel: 1
{
[STATE]: 00
}
Channel: 0
{
[UNREACH]: 00
[GROUP_STATE]: 00
[LAST_PACKET_RECEIVED]: 5c 5c 52 db
[RSSI_DEVICE]: b6
[STICKY_UNREACH]: 00
}
Channel: 4
{
[STATE]: 00 etc...........
Anbei auch das log mit degublevel 5:
02/07/19 16:55:15.708 Debug (My-IT-CUL): Packet 6666A65A6699969614 enters raisePacketReceived.
02/07/19 16:55:15.709 Debug (My-IT-CUL): Packet 6666A65A6699969614 is now passed to the EventHandler.
02/07/19 16:55:15.708 Intertechno packet received from 01574D6A (RSSI: -67 dBm): 01
02/07/19 16:55:15.709 RPC client: Debug: Calling RPC method "system.multicall" on server 192.168.XXX.XX.
02/07/19 16:55:15.709 RPC client: Parameters:
02/07/19 16:55:15.709 Module Intertechno: Info: STATE on channel 10 of peer 11 with serial number ITD01574D6A was set to 0x01.
(Array length=1)
{
(Struct length=2)
{
[methodName]
{
(String) event
}
[params]
{
(Array length=4)
{
(String) RF-1c2190fb
(String) ITD01574D6A:0
(String) RSSI_DEVICE
(Integer) -189
}
}
}
}
02/07/19 16:55:15.708 Please use one of the following addresses for device creation (possible device types: 0x10 to 0x1F): 0x02/07/19 16:55:15.709 Debug: Calling getFileDescriptor...
01574D6A or 0x81574D6A
02/07/19 16:55:15.709 Debug: Connecting to host 192.168.XXX.XX on port 9126...
02/07/19 16:55:15.709 Debug (My-IT-CUL): Packet processing of packet 6666A65A6699969614 took 0 ms.
02/07/19 16:55:15.710 Debug: Connected to host 192.168.XXX.XX on port 9126. Client number is: 84
02/07/19 16:55:15.710 RPC client: Debug: Sending packet: 42696E00000000980000001073797374656D2E6D756C746963616C6C00000001000001000000000100000101000000020000000A6D6574686F644E616D6500000003000000056576656E7400000006706172616D730000010000000004000000030000000B52462D3163323139306662000000030000000D49544430313537344436413A30000000030000000B525353495F44455649434500$
02/07/19 16:55:15.720 RPC client: Debug: Packet received: 42696E0100000015000001000000000100000003000000056576656E74
02/07/19 16:55:15.721 RPC client: Debug: Received packet from server 192.168.XXX.XX: 42696E0100000015000001000000000100000003000000056576656E74
02/07/19 16:55:15.721 RPC client: Response was:
(Array length=1)
{
(String) event
}
02/07/19 16:55:15.721 RPC client: Debug: Calling RPC method "system.multicall" on server 192.168.XXX.XX.
02/07/19 16:55:15.721 RPC client: Parameters:
(Array length=1)
{
(Struct length=2)
{
[methodName]
{
(String) event
}
[params]
{
(Array length=4)
{
(String) RF-1c2190fb
(String) ITD01574D6A:10
(String) STATE
(Boolean) 1
}
}
}
}
VG becksen
1 Like
Super und vielen Dank!
Ja, das Ganze ist aber auch im nächsten Stable, welches in einer Woche spätestens online sein sollte.
1 Like
Hallo @sathya,
leider funktioniert the kanal mit typ 0x10 noch nicht. Anbei der Auszug mit dl 5.
Der Hinweis im Log mit den möglichen Typen und Beispielen ist auf jeden Fall hilfreich. Ich habe auch beide Adressen probiert: 0x01574D6A or 0x81574D6A.
Beides geht aktuell nicht.
Anbei die genutzte Homegear version 0.7.30-1900
VG becksen
02/26/19 22:27:27.049 Debug (My-IT-CUL): Packet 6666A65A6699969625 enters raisePacketReceived.
02/26/19 22:27:27.049 Debug (My-IT-CUL): Packet 6666A65A6699969625 is now passed to the EventHandler.
02/26/19 22:27:27.049 Intertechno packet received from 01574D6A (RSSI: -62 dBm): 01
02/26/19 22:27:27.049 Please use one of the following addresses for device creation (possible device types: 0x10 to 0x1F): 0x01574D6A or 0x81574D6A
02/26/19 22:27:27.050 Debug (My-IT-CUL): Packet processing of packet 6666A65A6699969625 took 1 ms.
02/26/19 22:27:27.052 RPC client: Debug: Calling RPC method "system.multicall" on server 192.168.XXX.XXX.
02/26/19 22:27:27.052 RPC client: Parameters:
(Array length=1)
{
(Struct length=2)
{
[methodName]
{
(String) event
}
[params]
{
(Array length=4)
{
(String) RF-1c2190fb
(String) ITD01574D6A:0
(String) RSSI_DEVICE
(Integer) -194
}
}
}
}
02/26/19 22:27:27.053 Debug: Calling getFileDescriptor...
02/26/19 22:27:27.053 Debug: Connecting to host 192.168.XXX.XXX on port 9126...
02/26/19 22:27:27.054 Debug: Connected to host 192.168.XXX.XXX on port 9126. Client number is: 168
02/26/19 22:27:27.054 RPC client: Debug: Sending packet: 42696E00000000980000001073797374656D2E6D756C746963616C6C000000010000010000000001000001010000000200$
02/26/19 22:27:27.066 RPC client: Debug: Packet received: 42696E0100000015000001000000000100000003000000056576656E74
02/26/19 22:27:27.067 RPC client: Debug: Received packet from server 192.168.XXX.XXX: 42696E0100000015000001000000000100000003000000056576656E74
02/26/19 22:27:27.067 RPC client: Response was:
(Array length=1)
{
(String) event
}
02/26/19 22:27:34.306 Debug (My-IT-CUL): Packet 6666A65A6699959623 enters raisePacketReceived.
02/26/19 22:27:34.306 Debug (My-IT-CUL): Packet 6666A65A6699959623 is now passed to the EventHandler.
02/26/19 22:27:34.306 Intertechno packet received from 01574D6A (RSSI: -63 dBm): 00
02/26/19 22:27:34.306 Please use one of the following addresses for device creation (possible device types: 0x10 to 0x1F): 0x01574D6A or 0x81574D6A
02/26/19 22:27:34.307 Debug (My-IT-CUL): Packet processing of packet 6666A65A6699959623 took 1 ms.
02/26/19 22:27:35.611 RPC Server (Port 2001): Debug: Packet received: 42696E000000001C0000000470696E670000000100000003000000083163323139306662
02/26/19 22:27:35.611 RPC Server (Port 2001): Info: Client number 116 is calling RPC method: ping (2) Parameters:
(String) 1c2190fb
02/26/19 22:27:35.611 RPC Server (Port 2001): Response:
(Boolean) 1