So, damit ich den gepinnten Threat nicht vollspamme mache ich hier einmal einen eigenen Threat auf.
Also ich habe jetzt die beiden Zeilen:
apt-get install build-essential libusb-1.0-0-dev make gcc git-core
git clone git://git.zerfleddert.de/hmcfgusb
Die Zeilen sehen also folgendermaßen aus:
#!/bin/sh
cd /opt/
cd hmcfgusb
make
cat > /etc/init.d/hmland <<"EOF"
#!/bin/sh
# simple init for hmland
### BEGIN INIT INFO
# Provides: hmland
# Required-Start: $network $local_fs $remote_fs
# Required-Stop:: $network $local_fs $remote_fs
# Should-Start: $all
# Should-Stop: $all
# Default-Start: 2 3 4 5
aus dem script entfernt, gespeichert und dann den Pi neu gestartet.
Der Homeatic Stick ist leider immer noch disconnected. Leider :(
So sollte das aussehen:
#!/bin/sh
cat > /etc/init.d/hmland <<"EOF"
#!/bin/sh
# simple init for hmland
### BEGIN INIT INFO
# Provides: hmland
# Required-Start: $network $local_fs $remote_fs
# Required-Stop:: $network $local_fs $remote_fs
# Should-Start: $all
# Should-Stop: $all
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start hmland daemon at boot time
# Description: Provide Service to use HM-USB-CFG Adapter for FHEM.
### END INIT INFO
pidfile=/var/run/hmland.pid
port=1234
case "$1" in
start|"")
chrt 50 /opt/hmcfgusb/hmland -r 0 -d -P -l 127.0.0.1 -p $port 2>&1 | perl -ne '$|=1; print localtime . ": [hmland] $_"' >> /var/log/hmland.log &
;;
restart|reload|force-reload)
echo "Error: argument '$1' not supported" >&2
exit 3
;;
stop)
killall hmland
;;
status)
if [ ! -e $pidfile ]; then
echo "No pid"
exit 1
fi
pid=`cat $pidfile`
if kill -0 $pid &>1 > /dev/null; then
echo "Running"
exit 0
else
rm $pidfile
echo "Not running"
exit 1
fi
;;
*)
echo "Usage: hmland [start|stop|status]" >&2
exit 3
;;
esac
EOF
sudo chmod 755 /etc/init.d/hmland
sudo update-rc.d hmland defaults
sudo service hmland start
Stimmt, make war ja auch schon gelaufen, kann also auch raus.
Leider geht aus der Beschreibung nicht hervor, was genau nicht geklapt hat.
Bitte Ausgaben von ps -ef | grep hmland
ls -l /etc/init.d/hml*
ls -l /opt/hmcfgusb/
und cat /etc/init.d/hmland
posten.
es ist echt super, dass ihr Euch der Sache so annehmt. 100 dank dafür, denn ohne Eure Hilfe bin ich echt aufgeschmissen. Ich taste mich seit Anfang des Jahres nur lagnsam an das Gebiet FHEM heran und muss noch viel lernen.
Ich werde heute Abend die Kommandos ausführen und bereichten. Kurze Frage dazu: Muss der Befehl im Root erfolgen ?
Zitat von: Joker2002 am 08 Oktober 2015, 07:12:29
Ich werde heute Abend die Kommandos ausführen und bereichten. Kurze Frage dazu: Muss der Befehl im Root erfolgen ?
nein, muss nicht
so, da bin ich wieder.
Habe die von Dir angeforderten Befehle per Putt ausgeführt. Folgendes ist dabei herausgekommen:
Zitatps -ef | grep hmland
pi 3214 3199 0 19:58 pts/0 00:00:00 grep --color=auto hmlandZitatls -l /etc/init.d/hml*
-rwxr-xr-x 1 root root 1045 Oct 7 23:58 /etc/init.d/hmland
total 684
-rw-r--r-- 1 root root 365 Oct 1 21:38 20-hmlan.OpenWRT
-rw-r--r-- 1 root root 42361 Oct 1 21:38 aes.c
-rw-r--r-- 1 root root 19 Oct 1 21:39 aes.d
-rw-r--r-- 1 root root 7589 Oct 1 21:38 aes.h
-rw-r--r-- 1 root root 50624 Oct 1 21:39 aes.o
-rw-r--r-- 1 root root 4068 Oct 1 21:38 culfw.c
-rw-r--r-- 1 root root 25 Oct 1 21:39 culfw.d
-rw-r--r-- 1 root root 1607 Oct 1 21:38 culfw.h
-rw-r--r-- 1 root root 9020 Oct 1 21:39 culfw.o
drwxr-xr-x 3 root root 4096 Oct 1 21:38 debian
-rw-r--r-- 1 root root 4456 Oct 1 21:38 firmware.c
-rw-r--r-- 1 root root 41 Oct 1 21:39 firmware.d
-rw-r--r-- 1 root root 1349 Oct 1 21:38 firmware.h
-rw-r--r-- 1 root root 9508 Oct 1 21:39 firmware.o
-rwxr-xr-x 1 root root 43970 Oct 7 21:36 flash-hmcfgusb
-rw-r--r-- 1 root root 4801 Oct 1 21:38 flash-hmcfgusb.c
-rw-r--r-- 1 root root 80 Oct 1 21:39 flash-hmcfgusb.d
-rw-r--r-- 1 root root 11940 Oct 1 21:39 flash-hmcfgusb.o
-rwxr-xr-x 1 root root 113436 Oct 7 21:36 flash-ota
-rw-r--r-- 1 root root 22867 Oct 1 21:38 flash-ota.c
-rw-r--r-- 1 root root 90 Oct 1 21:39 flash-ota.d
-rw-r--r-- 1 root root 36704 Oct 1 21:39 flash-ota.o
-rw-r--r-- 1 root root 1871 Oct 1 21:38 hexdump.h
-rw-r--r-- 1 root root 2987 Oct 1 21:38 hm.c
-rw-r--r-- 1 root root 14104 Oct 1 21:38 hmcfgusb.c
-rw-r--r-- 1 root root 44 Oct 6 18:59 hmcfgusb.d
-rw-r--r-- 1 root root 2015 Oct 1 21:38 hmcfgusb.h
-rw-r--r-- 1 root root 28796 Oct 6 18:59 hmcfgusb.o
-rw-r--r-- 1 root root 160 Oct 1 21:38 hmcfgusb.rules
-rw-r--r-- 1 root root 32 Oct 1 21:39 hm.d
-rw-r--r-- 1 root root 1918 Oct 1 21:38 hm.h
-rw-r--r-- 1 root root 0 Oct 6 18:59 hmland
-rw-r--r-- 1 root root 23720 Oct 1 21:38 hmland.c
-rw-r--r-- 1 root root 57 Oct 6 18:59 hmland.d
-rw-r--r-- 1 root root 44612 Oct 6 18:59 hmland.o
-rw-r--r-- 1 root root 7204 Oct 1 21:39 hm.o
-rwxr-xr-x 1 root root 41322 Oct 7 21:36 hmsniff
-rw-r--r-- 1 root root 7228 Oct 1 21:38 hmsniff.c
-rw-r--r-- 1 root root 52 Oct 1 21:39 hmsniff.d
-rw-r--r-- 1 root root 18152 Oct 1 21:39 hmsniff.o
-rw-r--r-- 1 root root 1081 Oct 1 21:38 LICENSE
-rw-r--r-- 1 root root 0 Oct 7 21:33 make
-rw-r--r-- 1 root root 752 Oct 1 21:38 Makefile
-rw-r--r-- 1 root root 687 Oct 1 21:38 Makefile.OpenWRT
-rw-r--r-- 1 root root 5993 Oct 1 21:38 README.md
-rw-r--r-- 1 root root 1770 Oct 1 21:38 util.c
-rw-r--r-- 1 root root 15 Oct 1 21:39 util.d
-rw-r--r-- 1 root root 1265 Oct 1 21:38 util.h
-rw-r--r-- 1 root root 3276 Oct 1 21:39 util.o
-rw-r--r-- 1 root root 28 Oct 1 21:38 version.hZitatcat /etc/init.d/hmland
#!/bin/sh
# simple init for hmland
### BEGIN INIT INFO
# Provides: hmland
# Required-Start: $network $local_fs $remote_fs
# Required-Stop:: $network $local_fs $remote_fs
# Should-Start: $all
# Should-Stop: $all
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start hmland daemon at boot time
# Description: Provide Service to use HM-USB-CFG Adapter for FHEM.
### END INIT INFO
pidfile=/var/run/hmland.pid
port=1234
case "$1" in
start|"")
chrt 50 /opt/hmcfgusb/hmland -r 0 -d -P -l 127.0.0.1 -p $port 2>&1 | perl -ne '$|=1; print localtime . ": [hmland] $_"' >> /var/log/hmland.log &
;;
restart|reload|force-reload)
echo "Error: argument '$1' not supported" >&2
exit 3
;;
stop)
killall hmland
;;
status)
if [ ! -e $pidfile ]; then
echo "No pid"
exit 1
fi
pid=`cat $pidfile`
if kill -0 $pid &>1 > /dev/null; then
echo "Running"
exit 0
else
rm $pidfile
echo "Not running"
exit 1
fi
;;
*)
echo "Usage: hmland [start|stop|status]" >&2
exit 3
;;
esac
Zitat von: Joker2002 am 08 Oktober 2015, 20:04:00
pi 3214 3199 0 19:58 pts/0 00:00:00 grep --color=auto hmland
Zitat
Schlecht. Im Sinne hmland läuft anscheinen nicht
Das Program ist jedoch kompiliert und an der richtigen Stelle.
Start-Script auch vorhanden. Hast Du den Pi neugestsartet?
was liefert
sudo service hmland status
?
-rw-r--r-- 1 root root 0 Oct 6 18:59 hmland
hmland hat 0 Byte.
Das sollte aber in etwa so aussehen:
-rwxr-xr-x 1 root root 105572 Jun 21 12:45 hmland
Geht?
/opt/hmcfgusb/hmland -p 1234 -D
Ich denke nein ...
Schlage folgendes vor, da der Rest ja gut aussieht:
cd /opt/hmcfgusb
make clean
make
Wenn alles durchgelaufen ist:
ls -l hmland
Das sollte jetzt mehr als 0 Byte anzeigen. Wenn ja Neustart.
Falls vorher Fehlermeldungen bei make bitte posten.
MfG
Hallo Ralf,
wenn ich den Befehl
Zitatmake clean
erhalte ich folgende Fehler:
pi@raspberrypi /opt/hmcfgusb $ make clean
rm -f hmcfgusb.o hmland.o util.o hmcfgusb.o hmsniff.o hmcfgusb.o firmware.o util.o flash-hmcfgusb.o hmcfgusb.o culfw.o firmware.o util.o flash-ota.o hm.o aes.o hmcfgusb.d hmland.d util.d hmcfgusb.d hmsniff.d hmcfgusb.d firmware.d util.d flash-hmcfgusb.d hmcfgusb.d culfw.d firmware.d util.d flash-ota.d hm.d aes.d hmland hmsniff flash-hmcfgusb flash-ota
rm: cannot remove `hmcfgusb.o': Permission denied
rm: cannot remove `hmland.o': Permission denied
rm: cannot remove `util.o': Permission denied
rm: cannot remove `hmcfgusb.o': Permission denied
rm: cannot remove `hmsniff.o': Permission denied
rm: cannot remove `hmcfgusb.o': Permission denied
rm: cannot remove `firmware.o': Permission denied
rm: cannot remove `util.o': Permission denied
rm: cannot remove `flash-hmcfgusb.o': Permission denied
rm: cannot remove `hmcfgusb.o': Permission denied
rm: cannot remove `culfw.o': Permission denied
rm: cannot remove `firmware.o': Permission denied
rm: cannot remove `util.o': Permission denied
rm: cannot remove `flash-ota.o': Permission denied
rm: cannot remove `hm.o': Permission denied
rm: cannot remove `aes.o': Permission denied
rm: cannot remove `hmcfgusb.d': Permission denied
rm: cannot remove `hmland.d': Permission denied
rm: cannot remove `util.d': Permission denied
rm: cannot remove `hmcfgusb.d': Permission denied
rm: cannot remove `hmsniff.d': Permission denied
rm: cannot remove `hmcfgusb.d': Permission denied
rm: cannot remove `firmware.d': Permission denied
rm: cannot remove `util.d': Permission denied
rm: cannot remove `flash-hmcfgusb.d': Permission denied
rm: cannot remove `hmcfgusb.d': Permission denied
rm: cannot remove `culfw.d': Permission denied
rm: cannot remove `firmware.d': Permission denied
rm: cannot remove `util.d': Permission denied
rm: cannot remove `flash-ota.d': Permission denied
rm: cannot remove `hm.d': Permission denied
rm: cannot remove `aes.d': Permission denied
rm: cannot remove `hmland': Permission denied
rm: cannot remove `hmsniff': Permission denied
rm: cannot remove `flash-hmcfgusb': Permission denied
rm: cannot remove `flash-ota': Permission denied
Makefile:27: recipe for target 'clean' failed
make: *** [clean] Error 1muss ich da noch was an den Rechten beachten ?
Zitat von: Ralf W. am 08 Oktober 2015, 21:35:49
-rw-r--r-- 1 root root 0 Oct 6 18:59 hmland
hmland hat 0 Byte.
Oh, herrje, war der Tag wohl etwas zu lang, sehe elementare Sachen nicht :(
Zitat von: Joker2002 am 08 Oktober 2015, 23:00:10
muss ich da noch was an den Rechten beachten ?
probiere sudo make clean
dann sudo make
Hallo Hexenmeister,
hallo Ralf W.,
ihr seid klasse. Mit eurer Hilfe habe ich es jetzt geschafft, dass der HMLAN als Status: opened ist. Noch eine letzte Verständnisfrage: bei meinem Cul ist der vergleichsweise Status:Initialized.
Ist das gleichzusetzen mit dem Status des HMLAN Sticks?
Vielen Dank nochmal für Eure Hilfe :)
Zitat von: Joker2002 am 09 Oktober 2015, 17:48:18
Ist das gleichzusetzen mit dem Status des HMLAN Sticks?
Ich denke schon, mein (echter) HMLAN und HMUSB zeigen beide "opened".
Da kocht hjedes Modul scheinbar eigene Suppe.
(http://forum.fhem.de/index.php?action=dlattach;topic=41938.0;attach=38491;image)
Mein HM-USB mit hmland angesteuert zeigt auch nur open, aber im log kann ich ablesen:
HMLAN_Parse: hm_usb2 new condition init
........
........
HMLAN_Parse: hm_usb2 new condition ok
und funktioniert einwandfrei
Ich muss mich leider nochmal einklinken. Die Hürde der Einrichtung des HMLAN USB Sticks ist ja dank euer Hilfe erfolgreich gelungen. Jedoch erhalte ich jetzt minütlich Fehler im Logfile (ähnlich dieser hier):
2014-06-11 08:56:35 HMLAN HMLAN1 UNKNOWNCODE A0F0F861022C10A0000000A88F40E000F::-104:HMLAN1
2014-06-11 08:58:15 HMLAN HMLAN1 UNKNOWNCODE A0FA9861022BF630000000A88F60E000F::-92:HMLAN1
2014-06-11 08:59:30 HMLAN HMLAN1 UNKNOWNCODE A0F10861022C10A0000000A88F40E000F::-103:HMLAN1Ich habe nach dem Fehler gesucht und im entsprechenden im Wiki gelesen, dass eine Virtuelle VCCU angelegt werden soll. Das Wiki an sich ist für mich jedoch nicht so ganz verständlich..
Hier steht zur HMId wählen folgendes:
ZitatEine VCCU benötigt wie alle HM Devices eine Adresse, mit der sie angesprochen wird. Diese muss eindeutig in System sein. Man muss also eine noch nicht verwendete wählen.
Eindeutig ist im Bereich CUL_HM. Eine HMId eines IO kann/sollte verwendet werden da diese keine CUL_HM Devices sind.
Bedeutet dass, ich denke mir einfach eine HMId aus ? oder ergibt diese sich aus dem unknown code wie folgt:
ZitatA0EFF8202113EE01143930101000043
wird zerlegt in
Code: [Auswählen]
A 0E FF 82 02 113EE0 114393 0101000043
A : HM Message indicator
0E: Message length (0E -> 14 Byte)
FF: Message counter
82: Communication bit field
02: Message type
113EE0: Source ID (Absender)
114393: Target ID (Empfänger)
0101000043: Payload (Nachrichteninhalt)
Hier müsste ich dann die Target ID wählen ? Oder verstehe ich das falsch ?
ZitatOder verstehe ich das falsch ?
ja.
du nimmst am besten deine bisherige zentralen-hmid, mit der deine devices gepaired sind. du kannst dir natürlich auch eine neue wählen, wodurch dann alle devices neu gepaired werden müssen.
Ok, besten Dank, dann werde ich das heute Abend mal ausprobieren :)
Zitat von: Joker2002 am 09 Oktober 2015, 17:48:18
Mit eurer Hilfe habe ich es jetzt geschafft, dass der HMLAN als Status: opened ist. Noch eine letzte Verständnisfrage: bei meinem Cul ist der vergleichsweise Status:Initialized.
Ist das gleichzusetzen mit dem Status des HMLAN Sticks?
das kannst du ja umbenennen, so in der Art:
{ Value('HMLAN') eq 'opened' ? 'Aktiv' : 'nicht aktiv' }
{ (Value('HMUSB') eq 'opened' ? 'Aktiv' : 'nicht aktiv') }
So, ich habe jeztzt mal folgende Befehle eingegen um mein oben genanntes Problem zu lösen:
define vccu CUL_HM 424242
attr vccu model CCU-FHEM leider ohne Erfolg. Die Fehlermeldungen:
Zitat2015.10.12 20:20:57 3: hmusb: Unknown code A0A0180022B72BD3D960F00::-89:hmusb, help me!
2015.10.12 20:20:57 3: hmusb: Unknown code A0B01A0012B72BD3D9617010E::-89:hmusb, help me!
2015.10.12 20:20:57 3: hmusb: Unknown code A0A0180022B72BD3D961700::-90:hmusb, help me!
2015.10.12 20:21:00 3: hmusb: Unknown code A11E4A0022B72BD36354304144F00004F1300::-91:hmusb, help me!
2015.10.12 20:21:00 3: hmusb: Unknown code A0EE480022B72BD36354300420DAF5D::-92:hmusb, help me!
2015.10.12 20:21:02 3: hmusb: Unknown code A11E5A0022B72BD36354304BE480000481200::-92:hmusb, help me!
2015.10.12 20:21:02 3: hmusb: Unknown code A0EE580022B72BD36354300E6B7E764::-91:hmusb, help me!
2015.10.12 20:22:42 3: hmusb: Unknown code A0C7586702F23F600000000553F::-80:hmusb, help me!
kommen noch fast minütlich :(
Ich poste hier mal meine Einstellungen meines HomeLan USB und meiner VCCU in der Hoffnung jemand von Euch kann mir noch einen Tipp geben :-\
HMLAN USB
DEF 127.0.0.1:1234
DeviceName 127.0.0.1:1234
FD 197
IFmodel USB
NAME hmusb
NR 779
NTFY_ORDER 50-hmusb
PARTIAL
RAWMSG E2F23F6,0000,0E78A0E4,FF,FFB0,7286702F23F600000000563F
RSSI -80
STATE opened
TYPE HMLAN
XmitOpen 1
assignedIDsCnt 1
hmusb_MSGCNT 7070
hmusb_TIME 2015-10-12 20:15:36
msgKeepAlive dlyMax:0.031 bufferMin:4
msgLoadCurrent 0
msgLoadHistory 5min steps: 0/0/0/0/0/0/0/0/0/0/0/0
msgParseDly min:-49 max:140 last:54 cnt:6774
owner 424242
uptime 002 67:26:26.532
Readings
D-HMIdAssigned 424242 2015-10-10 00:49:08
D-HMIdOriginal 34F22A 2015-10-10 00:49:08
D-firmware 0.964 2015-10-10 00:49:08
D-serialNr LEQ1517341 2015-10-10 00:49:08
Xmit-Events ok:2 disconnected:3 init:3 2015-10-10 00:49:08
cond ok 2015-10-10 00:49:08
loadLvl low 2015-10-12 20:17:35
prot_disconnected last 2015-10-10 00:49:06
prot_init last 2015-10-10 00:49:06
prot_ok last 2015-10-10 00:49:08
state opened 2015-10-10 00:49:06
VCCU
CFGFN
DEF 424242
NAME vccu
NR 1787
NTFY_ORDER 50-vccu
STATE hmusb:UAS
TYPE CUL_HM
assignedIOs hmusb
Attributes
autoReadReg 4_reqStatus
expert 2_full
model CCU-FHEM
subType virtual
webCmd virtual:update
Hallo,
wie die Message aufgebaut ist, steht doch etwas weiter vorne
A 0A 01 80 02 2B72BD 3D960F 00 = Gerät 3D960F sendet an 2B72BD.
Wer da was ist, musst Du in deiner Konfiguration nachsehen. Da die Geräte an 2B72BD senden, sind sie an dieses Gerät gepairt.
Also ich würde Dir raten - nachdem Du eine VCCU hast und der HMCFGUSB läuft - alle Geräte aus fhem löschen, alle Geräte resetten und ganz von vorne anfangen mit pairen. Oder nachsehen welche Geräte das sind und diese neu pairen.
Gruß Christoph
Derzteit habe ich noch gar kein Homematic fähiges Gerät installiert bzw. in Betrieb genommen (bisher nur den USB Stick).
Sicher dass ich all meine anderen Geräte deswegen löäschen soll ?
Hallo,
dann natürlich nichts löschen - aber irgendwelche HM Daten bekommst Du rein - vom Nachbarn ? Ist autocreate on ?
Gruß Christoph
ja autocreate ist "active"
HMLAN, HMUSB und VCCU müssen die gleiche sechsstellige ID haben und nicht die der Nachbarn:
Wenn alles korrekt eingerichtet ist, hast Du kein Problem mit den Nachbarn. In den Readings der VCCU steht dann so etwas:
unknown_15A9A2 received 2015-10-12 19:25:29
unknown_1D438A received 2015-10-12 12:05:10
unknown_249FB4 received 2015-05-28 11:28:48
Und Ruhe ist.
MfG
Hallo,
@Ralf W.
ZitatHMId wählen
Eine VCCU benötigt wie alle HM Devices eine Adresse, mit der sie angesprochen wird. Diese muss eindeutig in System sein. Man muss also eine noch nicht verwendete wählen.
Eindeutig ist im Bereich CUL_HM. Eine HMId eines IO kann/sollte verwendet werden da diese keine CUL_HM Devices sind.
Also sollten / können nicht alle IO's und die VCCU die gleiche ID haben.
Gruß Christoph
Hm, ich muss sagen dass mich die Aussage als Anfänger verwirrt.
Ich habe jetzt eine neue HMId (564976) gesetzt und diese auch in der VCCU so eingegeben.
Trotzdem erhalte ich diese Fehlermeldung.
Wo genau muss ich denn die sechsstellige ID eingeben bzw. was genau meinst Du mit der sechselligen ID wenn es nicht die HMId ist ?
Sorry, dass ich nur ID geschrieben habe.
Also:
HMId (564976)
Diese muss bei HMLAN, HMUSB und VCCU identisch sein.
Wenn Du nur HMUSB und VCCU hast, dann nur bei den beiden gleich.
MfG
Hallo,
also die HMid ist ein attribut des / der HMUSB oder VCCU. Ob man anschießend ein rereadcfg machen muss, weiß ich nicht.
Suche mal im Forum - Abschnitt Homematic nach "Nachbarn". Vielleicht wirdt Du da fündig, wie Du das abstellen kannst.
@Ralf W. - im WIKI steht das mit der ID anders.
Gruß Christoph
die HMId ist bei mir gleich, sowohl bei der VCCU als auch bei dem Homematik USB Stick.
@Bennemannc
Im Wiki steht das mit der ID nicht anders. Bitte den ganzen Abschnitt lesen.
@Joker2002
Wenn der Fehler immer noch auftaucht, bitte die Suchfunktion benutzen. Zu dem Thema gibt es "gefühlte" 18734 Einträge.
MfG
Zitatleider ohne Erfolg.
kein wunder, wenn das alles ist:
define vccu CUL_HM 424242
attr vccu model CCU-FHEM da fehlt mindestens attr iolist und attr subtype.
das wiki und unzählige threads, sollten das doch zeigen.
Zitat von: Bennemannc am 12 Oktober 2015, 21:46:18
@Ralf W. Also sollten / können nicht alle IO's und die VCCU die gleiche ID haben.
das ist natürlich unsinn.
die vccu ist der io-manager/verwalter der zentrale (fhem). die zentrale benötigt eine eindeutige hmid, welche in der definition der vccu eingetragen ist. wenn die io's, die der vccu mit dem attr iolist zugeordnet/assigned sind, bereits eine andere hmid haben, wird die vccu diesen io's automatisch ihre hmid zuweisen, damit alle io's im namen der selben zentrale funken können.
So, habe mein Problem folgendermaßen gelösst:
Fehlermeldung:
2015.10.12 20:20:57 3: hmusb: Unknown code A0A018002 2B72BD 3D960F00::-89:hmusb, help me!
2015.10.12 20:22:42 3: hmusb: Unknown code A0C758670 2F23F6 00000000553F::-80:hmusb, help me!
Lösung:
bei mir senden 2 Devices, die CUL_HM nicht kennt:2B72BD und 2F23F6
Die Devices definieren und auf ignore setzen.
Und zwar so:
define nachbar1 CUL_HM 2B72BD
attr nachbar1 ignore 1
define nachbar2 CUL_HM 2F23F6
attr nachbar2 ignore 1
...vielleicht hilft es mal jemanden weiter, der vor einem ähnlichen Problem steht, wie ich.
Danke für Eure Hilfe !
dann läuft deine vccu also immer noch nicht?
.also ich habe sie gemaß dem WIKI eingerichtet, habe die HMId meines Homatik Stick gemäß den Angaben eingerichtet und das attr vccu model CCU-FHEM gesetzt.
Das
Zitatattr vccu IOList <io1>[,<io2>,...]
habe ich noch nicht eingestellt, da ich derzeit noch keine Homeatic Geräte am Start habe und diese, so wie ich es verstgehe, erst eingeben kann, wenn ich diese mit FHEM Pairen will.
Hallo,
nicht ganz so - Du hast doch ein IO-Gerät am Start, also kannst Du das doch in die IOList eintragen. Das solltest Du auch vor dem ersten pairen machen, da Du ja dann das hmPairSec an der VCCU aufrufst und die ja schauen muss über welches IO sie denn jetzt mit dem neuen HM-Gerät reden soll.
Gruß Christoph
verstehe ich das dann richtig, dass ich in meinem Fall für "io1" die HMId meines Homematic Stick eintrage ?
also in meinem Fall:
attr vccu IOList 424242 ?
nein, den namen des io device.
Hallo,
Du hast in Deiner Config etwas wie "define HMLAN1 HMLAN 127.0.0.1:1000"
dann müsste es heißen: "attr vccu IOList HMLAN1"
Gruß Christoph
danke für die Aufklärung. Werde ich heute Abend gleich noch einstellen :)