Homegear Konfiguration für Intertechno Geräte

Deutsche Foren Konfiguration
#1

Hallo,

ich versuche auf dem RPI3 mit einem Busware COC zusätzlich zu homematic auch noch das Intertechno Gerät PIR-1000 (Bewegungsmelder) ans Laufe zu bekommen. Dazu verwende ich Openhab 2.2.0

Ich habe die Homegear Doku verwendet: https://doc.homegear.eu/data/homegear-intertechno/adding_devices.html

Leider kann ich nicht feststellen ob das Pairing funktioniert und wie es prüfen kann. Meine Konfiguration sieht folgendermaßen aus.

######### COC, SCC, CSM, CCD  #########
#######################################

## The device family this interface is for
#[COC, SCC, CSM, CCD]

## Specify an unique id here to identify this device in Homegear
#id = My-COC
id = My-COC
## When default is set to "true" Homegear will assign this device
## to new peers.
#default = true
default = true

#deviceType = coc
deviceType = coc

#device = /dev/ttyAMA0
device = /dev/ttyAMA0

## Default: gpio1 = 0
## "17" for COC, SCC and CCD. Empty for CSM.
gpio1 = 17

## Default: gpio2 = 0
## "18" for COC and SCC. "22" for CCD. Empty for CSM.
gpio2 = 18

## Default: stackPosition = 0 (= no stacking)
## Set stackPosition if you use the SCC and stacked multiple devices.
## Set stackPosition to "1" for the lowest device, to "2" for the device
## above that and so on.
# stackPosition = 0

Danke.

OH2 und Intertechno Sensor
#2

Du musst die Sektion einkommentieren :slight_smile:

#3

Hallo pmeyer,

danke für die schnelle Rückmeldung.
Bittere Fehlleistung meinerseits :frowning:

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

#4

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.

#5

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.

https://wiki.fhem.de/wiki/COC

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
#6

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.

#7

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.

Parallelbetrieb mit unterschiedlichen Protokollen

#8

Der Artikel bezieht sich auf FHEM. Meines Wissens nach ist es in Homegear nicht implementiert. Da kann aber @sathya sicher was zu sagen.

#9

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
#10

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.

COC flashen

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

#11

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.

#12

Hallo @becksen,

genauso wie den normalen CUL. Siehe https://doc.homegear.eu/data/homegear-intertechno/configuration.html#config-cul.

Viele Grüße

Sathya

#13

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.

#14

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

#15

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

#16

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
#17

Das Problem sollte im nächsten Nightly behoben sein. Siehe: Integration Smartwares SH5-TSO-A (Bewegungsmelder)

#18

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ß

#19

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
#20

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