HM-MOD-RPI-PCB Installations Problem hmID

Begonnen von Scotch, 04 Oktober 2017, 22:09:10

Vorheriges Thema - Nächstes Thema

Scotch

Moin,
ich habe an meinem Raspberry Pi 3 das HM-OCCU Funkmodul und versuche es gerade nach der Anleitung
https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
in Betrieb zu nehmen.
Bei dem Punkt
ZitatDefinition in FHEM
define myHmUART HMUARTLGW /dev/ttyAMA0
attr myHmUART hmId xxxxxx
komme ich nicht weiter.
Wie finde ich die hmID heraus?
Hab schon mal die 2D Datamatrix Code gescannt.
Aber keiner der Werte war jetzt irgend wie schlüssig.
Oder ist die ID frei wählbar?
Ein Hinweis in der Anleitung wäre da sehr hilfreich.
Gruß Ingo


Scotch

Ok,
ich denke ich habe die Lösung hier gefunden.
https://wiki.fhem.de/wiki/HomeMatic_Installieren

Sprich die ID kann selbst vergeben werden.


Scotch

Soweit so gut.

ZitatDefinition in FHEM
define myHmUART HMUARTLGW /dev/ttyAMA0
attr myHmUART hmId 0000a1
hat geklappt, gab zumindest erst mal keine Fehlermeldung.

Wenn ich Fhem neu starte bekomme ich diese Meldung

ZitatMessages collected while initializing FHEM:
./log/fhem.save: Please define myHmUART first
Please define myHmUART first
Please define myHmUART first
Please define myHmUART first
Please define myHmUART first
Please define myHmUART first
Please define myHmUART first
Please define myHmUART first
Please define myHmUART first
Please define myHmUART first

Wenn ich dann wider define myHmUART HMUARTLGW /dev/ttyAMA0
eingebe meckert Fhem das ich das device vorher löschen soll

Die Firmware von dem Funk Modul habe ich von 1.2.1 auf 1.4.1 aktualisiert
Wenn ich list HMUARTLGW eingebe, bekomme ich das angezeigt.

Zitat
Internals:
   AssignedPeerCnt 0
   CFGFN
   CNT        34
   DEF        /dev/ttyAMA0
   DEVCNT     34
   DevState   99
   DevType    UART
   DeviceName /dev/ttyAMA0@115200
   FD         11
   LastOpen   1507151034.56801
   NAME       myHmUART
   NR         26
   PARTIAL
   RAWMSG     040200
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   1
   msgLoadCurrent 0
   msgLoadHistory -/-/-/-/-/-/-/-/-/-/-/-
   msgLoadHistoryAbs 0/-/-/-/-/-/-/-/-/-/-/-/-
   owner      5842B6
   Helper:
     CreditTimer 19
     FW         66561
     Initialized 1
     AckPending:
     LastSendLen:
       3
       3
     Log:
       IDs:
     RoundTrip:
       Delay      0.00337386131286621
     loadLvl:
       lastHistory 1507151038.12066
   Peers:
   READINGS:
     2017-10-04 23:03:58   D-HMIdAssigned  5842B6
     2017-10-04 23:03:58   D-HMIdOriginal  5842B6
     2017-10-04 23:03:58   D-firmware      1.4.1
     2017-10-04 23:03:58   D-serialNr      OEQ0306749
     2017-10-04 23:02:21   D-type          HM-MOD-UART
     2017-10-04 23:03:58   cond            ok
     2017-10-04 23:03:58   load            0
     2017-10-04 23:03:58   loadLvl         low
     2017-10-04 23:03:54   state           opened
Attributes:

Für heute ist erst mal Feierabend :-)
Mal schauen ob es Morgen ein paar brauchbare Infos hier gibt.

BTW. hab ja jetzt die Original hwID gesehen und dem entsprechend angepasst.

Gruß Ingo

Beta-User

Schön, dass du die Lösung zur HmID gefunden hast.

Ein paar Anmerkungen/Stichworte zum weiter Einarbeiten:
- vermutlich hast du erst einige HM-Devices definiert und dann erst das zugehörige IO (bzw. das danach gewechselt)?
- Wenn du mehrere IOs hast: Das Stichwort VCCU sagt dir was? (Kann auch helfen, wenn man hinterher IO's wechselt)
- Dein Thread-Titel ist m.E. suboptimal: Du hast keine OCCU (=separate Software für den PI von eQ-3, anzubinden in der Regel über das Modul HMCCU), sondern das PI-Modul (HM-MOD-RPI-PCB), angesprochen als IO für HM_CUL-Devices. Vielleicht wäre es besser, den ersten Thread-Titel entsprechend zu ändern.
- Erste Quelle für Fragen zu Modulen sollte IMMER die commandref sein, das (und nur das) ist die offizielle Doku. Erst danach kommen wiki und forum...
In der commandref findet sich unter HMUARTLGW der Hinweis auf das Attribut hmid mit dem Link, dass dies eine 6-stellige HEX-Angabe zu sein hat.

Nix für ungut und viel Spaß beim Einarbeiten,

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Scotch

Hallo Beta-User,

vielen Dank für deine Antwort.
Du hast mit dem Modul natürlich recht es ist ein HM-MOD-RPI-PCB. Ich hatte die Bezeichnung vom Beipackzettel übernommen.
Den Thread-Titel hab ich gleich angepasst.
Nach dem ich gestern bei Fhem noch mal ein Update gemacht hatte, waren die Fehlermeldungen auch verschwunden.
VCCU sagt mir erst mal nichts, vermute mal, das V steht für Virtual. 

z.Z hab ich 3 HM Thermostate, die werde ich heute mal versuchen mit Fhem zu verbinden.
Schauen wir mal ob das klappt.

Gruß Ingo

Beta-User

V steht für virtual, das ist richtig.

Mehr Info hier: https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU

Wenn du Homematic mit CUL_HM nutzt, ist es m.E. empfehlenswert, gleich eine VCCU einzurichten. Das kann einem später viel Ärger ersparen, auch wenn man nicht gleich versteht, was das eigentlich soll...

Viel Spaß jedenfalls,

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors