HMUARTLGW: Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway

[mgernoth]

Hallo,

als UART brachte das csmacd auf jeden Fall was ...

Habe ich gerade mal getestet und JA, keine spürbare Verzögerung mehr festzustellen 

Ok, schön zu hören
Wenn ich mich recht erinnere, deaktiviert eQ-3 zumindest auf dem HMCFGUSB auch CSMA/CA (ich hatte mir damals angeschaut, welche Register im CC1101 auf welche Werte gesetzt werden).

Ich will das aber nicht standardmäßig abschalten, weil das IMHO den Bestimmungen der BNetzA in diesem Frequenzband entgegenlaufen würde.

Viele Grüße
  Michael

[Ralli]

Du kannst es ruhig standardmäßig deaktivieren.

In der Allgemeinzuteilung heißt es:

Es sind Frequenzzugangs- und Störungsminderungstechniken einzusetzen, deren Leistung mindestens den Techniken entspricht, die in den gemäß Richtlinie 1999/5/EG bzw. des FTEG verabschiedeten harmonisierten Normen vorgesehen sind. Alternativ kann ein maximaler Arbeitszyklus) von 1% verwendet werden.

Wenn also Duty-Cycle von 1% als Technik verwendet wird, sind andere Dinge (wie lbt) nicht notwendig.

[mgernoth]

Hi,

Du kannst es ruhig standardmäßig deaktivieren.

Ist im Update von heute jetzt standardmaessig aus.

Viele Gruesse
  Michael

[hauwech]

Ergänzend eine kurze Info zum Thema HmUART-Device umbenennen:

• Umbenennen geht problemlos
• Man muß aber anschließend in der IOList der VCCU den neuen Namen händisch anpassen, das Attribut bekommt die Namensänderung nicht mit.

Gruß Roland

[marvin78]

Ergänzend eine kurze Info zum Thema HmUART-Device umbenennen:

   
• Umbenennen geht problemlos

Natürlich. Warum auch nicht?

   
• Man muß aber anschließend in der IOList der VCCU den neuen Namen händisch anpassen, das Attribut bekommt die Namensänderung nicht mit.

Natürlich. Attribute gehören dem User.

[hauwech]

Natürlich. Warum auch nicht?

Meine Frage war nur Vorsicht, weil alle anderen devices ein "set deviceRename..." haben und der UART nicht. Das könnte einen Grund haben, muß aber nicht.

Natürlich. Attribute gehören dem User.

Ich weiß nicht, wie fhem intern ein rename macht. Eine Möglichkeit wäre mit "Suchen und Ersetzen" in der fhem.cfg. Damit wären auch Attribute geändert. Wird aber offenbar anders gemacht.

Gruß Roland

[dev0]

Ich weiß nicht, wie fhem intern ein rename macht. Eine Möglichkeit wäre mit "Suchen und Ersetzen" in der fhem.cfg.

Einige Module reagieren in der Tat auf das Rename und ändern dann auch Defines, Internals und Attribute. Daher war die Frage schon richtig.

[hauwech]

Hallo dev null,
danke für die moralische Unterstützung 
Gruß Roland

[battery88]

Hallo Miteinander

Ich bin neu hier im Forum und beginne mit einigen einfachen Gebäudeautomatisationen mit Raspberry Pi 3 / FHEM und HomeMatic Komponenten.

Dafür möchte ich mir ein Gateway anschaffen, habe aber gehört, dass es Fehlermeldungen und Probleme gibt mit der Version EU-2 vom Gateway.

Da an folgendem Ort auch nur von der ersten Version geredet wird und nirgends die EU-2 erwähnt wird, frage ich mich vor der Anschaffung, ob es auch mit einem EU-2 reibungslos funktioniert? 
http://www.fhemwiki.de/wiki/HM-LGW-O-TW-W-EU_Funk-LAN_Gateway

HM-LGW-O-TW-W-EU-2

Vielen Dank für Eure Rückmeldung

Gruss Dani

[marvin78]

Einige Module reagieren in der Tat auf das Rename und ändern dann auch Defines, Internals und Attribute. Daher war die Frage schon richtig.

Das ist mir bewusst. Dass Attribute geändert werden ist sehr sehr selten und auch in sehr sehr vielen Fällen weder richtig noch notwendig. Wer sagt denn, dass das neu benannte Device tatsächlich der VCCU zugeordnet bleiben soll? Es wäre unlogisch, wenn hier etwas automatisch passieren würde. Attribute gehören dem User und wenn sie nicht zwingend zu einer Funktionsfähigkeit benötigt werden (was fast nie der Fall ist), sollte ein Modul (und schon mal gar nicht aus einem fremden Device) diese anfassen.

[dev0]

Wer sagt denn, dass das neu benannte Device tatsächlich der VCCU zugeordnet bleiben soll? Es wäre unlogisch, wenn hier etwas automatisch passieren würde.

Das sehe ich unter gewissen Umständen anders. Aber das gehört nicht in diesen Thread.

[mgernoth]

Hallo,

Dafür möchte ich mir ein Gateway anschaffen, habe aber gehört, dass es Fehlermeldungen und Probleme gibt mit der Version EU-2 vom Gateway.

Wo hast Du von Problemen mit der -2 Version gehört?

Da an folgendem Ort auch nur von der ersten Version geredet wird und nirgends die EU-2 erwähnt wird, frage ich mich vor der Anschaffung, ob es auch mit einem EU-2 reibungslos funktioniert?

Ich habe auch nur die -2 und damit das Modul entwickelt, es sollte also funktionieren

Viele Grüße
  Michael

[Ma_Bo]

Laut meinem Großhändler ist das HM-LGW-O-TW-W-EU ein Auslaufmodel und nur noch das HM-LGW-O-TW-W-EU-2 erhältlich...
Habe dieses seit heute und seit heute läuft es bisher stabil und alles ohne Probleme einzurichten.

Grüße Marcel

[gloob]

B

[Impulse]

Hallo Leute,

erst einmal ein dickes Lob an alle Beteiligten, die das alles möglich gemacht haben!

Ich habe aktuell das Problem, dass mein Modul in FHEM immer zwischen 'init' und 'disconnected' wechselt. Wie ich bisher vorgegangen bin:

Ich bin die Anleitung aus der FHEM-Wiki gewissenhaft durchgegangen und habe auch die Schritte von Betateilchen befolgt (ich habe einen Raspberry 3 mit Raspbian/Debian Jessie als OS). Ich konnte das Modul erfolgreich in FHEM integrieren, sowie auch schon eine Funksteckdose anlernen und schalten. Nun habe ich einen Busware CUL angeschlossen am Raspi, der eine FS20 Funksteckdose schalten soll. Diesen habe ich auch definiert in FHEM und ich kann auch wunderbar die FS20 Steckdose schalten. Allerdings kann ich jetzt nicht mehr via HM Funkmodul meine Steckdose ansteuern. 'Cond' (wofür auch immer das steht) wechselt immer wieder und wieder zwischen init und disconnected hin und her. Der Status bleibt auf 'Disconnected'. Ich habe bereits das Funkmodul nochmal neu raufgesteckt um auszuschließen, dass es evtl falsch angeschlossen war. Selbst nachdem ich den Busware-Stick abgezogen hatte und das Device aus FHEM entfernt habe funktioniert(e) es nicht.

Was mir aufgefallen ist:

Ich habe über FHEM versucht, die Firmware zu flashen. FHEM warf mir aber jedes Mal eine Fehlermeldung, dass die Datei keine gültige Firmware-Datei sei (ein Blick in den Log verrät, dass ich mich 1-2 mal beim Pfad verschrieben hatte, viel häufiger kam allerdings die Nachricht 'Permission Denied'. Auch nachdem ich der Firmware-Datei komplett alle Rechte gegeben habe. Wie es der Zufall will stand bei dem Modul in FHEM allerdings Firmware 1.4.1. Entweder war der Flash-Vorgang doch erfolgreich oder die Dinger werden mittlerweile mit dieser Version ausgeliefert. Weiß da einer mehr?

Ich habe außerdem versucht via dem Programm flash-hmmoduart mein Modul zu flashen. Leider schlägt dies fehl, da ich nur die Ausgabe bekommen, dass eine falsche Prüfsumme berechnet wurde.

Können meine Probleme evtl durch das möglicherweise fehlgeschlagene Flashen ausgelöst worden sein oder liegt das doch mit am Busware CUL Stick (falls relevant der Stick läuft im Modus 'RFSlow')? Oder aber Option 3: Es ist etwas völlig anderes.

Hier noch ein Auszug aus meiner Logdatei:

Code Auswählen Erweitern

2016.09.09 14:10:19 1: /dev/ttyAMA0 disconnected, waiting to reappear (HM_CUL)
2016.09.09 14:10:24 3: Setting HM_CUL serial parameters to 115200,8,N,1
2016.09.09 14:10:24 1: /dev/ttyAMA0 reappeared (HM_CUL)
2016.09.09 14:10:35 1: HMUARTLGW HM_CUL did not respond, reopening
2016.09.09 14:10:35 3: Setting HM_CUL serial parameters to 115200,8,N,1
2016.09.09 14:10:35 1: /dev/ttyAMA0 reappeared (HM_CUL)
2016.09.09 14:10:46 1: HMUARTLGW HM_CUL did not respond, reopening
2016.09.09 14:10:46 3: Setting HM_CUL serial parameters to 115200,8,N,1
2016.09.09 14:10:46 1: /dev/ttyAMA0 reappeared (HM_CUL)
2016.09.09 14:10:57 1: HMUARTLGW HM_CUL did not respond, reopening
2016.09.09 14:10:57 3: Setting HM_CUL serial parameters to 115200,8,N,1
2016.09.09 14:10:57 1: /dev/ttyAMA0 reappeared (HM_CUL)
2016.09.09 14:11:08 1: HMUARTLGW HM_CUL did not respond, reopening
2016.09.09 14:11:08 3: Setting HM_CUL serial parameters to 115200,8,N,1
2016.09.09 14:11:08 1: /dev/ttyAMA0 reappeared (HM_CUL)
2016.09.09 14:11:10 1: /dev/ttyAMA0 disconnected, waiting to reappear (HM_CUL)
2016.09.09 14:11:17 3: Setting HM_CUL serial parameters to 115200,8,N,1
2016.09.09 14:11:17 1: /dev/ttyAMA0 reappeared (HM_CUL)
2016.09.09 14:11:19 1: /dev/ttyAMA0 disconnected, waiting to reappear (HM_CUL)

Grüße