Homematic wired

Begonnen von Henne1977, 26 Januar 2013, 22:46:00

Vorheriges Thema - Nächstes Thema

Mirko Krause

Also kann man bei dem "HMW-Sen-SC-12-FM" (-> Schließerkontakt 12 Eingänge) die Eingänge nicht als Ausgänge in FHEM konfigurieren, obwohl man es - zumindest laut Bedienungsanleitung - mit einer HomeMatic-Zentrale tun könnte...? Und ich müßte den "HMW-IO-12-FM" (-> 12-fach I/O-Modul) für mein o.g. Anliegen in FHEM verwenden?

Richtig?

Btw.: Würde der "HMW_IO_4_FM" eigentlich auch gehen bzw. wird der auch von FHEM unterstützt?

Viele Grüße
Mirko
Raspberry Pi 2
HM485-LAN, HMW-Sen-SC-12-DR, HMW-IO-12-Sw14-DR, HMW-Sen-SC-12-FM, 4x HMW-LC-Sw2-DR (in Planung: EIB/KNX-Lan-Gateway)
Lichtsteuerung, Anwesenheitserkennung, Alarmmeldung

Ralf9

Zitat von: mkfhem am 24 Oktober 2015, 17:21:30
Also kann man bei dem "HMW-Sen-SC-12-FM" (-> Schließerkontakt 12 Eingänge) die Eingänge nicht als Ausgänge in FHEM konfigurieren, obwohl man es - zumindest laut Bedienungsanleitung - mit einer HomeMatic-Zentrale tun könnte...?
Das Modul hat nur Eingänge. Auf welcher Seite der Anleitung wird was von Ausgängen erwähnt?

Zitat von: mkfhem am 24 Oktober 2015, 17:21:30
Und ich müßte den "HMW-IO-12-FM" (-> 12-fach I/O-Modul) für mein o.g. Anliegen in FHEM verwenden?
Btw.: Würde der "HMW_IO_4_FM" eigentlich auch gehen bzw. wird der auch von FHEM unterstützt?
Ja, der HMW_IO_4_FM würde auch gehen. Er müsste von FHEM eigentlich auch unterstützt werden. Falls er noch nicht unterstützt wird, dürfte die Anpassung, wie Thorsten auch schon geschrieben hat, kein großes Problem sein.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Mirko Krause

Uuups, gar nicht!

Ich dachte auf Seite 13 in der Bedienungsanleitung, das war aber die Anleitung "90071_HMW_IO_12_FM_UM.pdf" vom HMW-IO-12-FM.

In der Bedienungsanleitung "90057_HMW_Sen_SC_12_FM_UM.pdf" auf Seite 12 vom HMW-Sen-SC-12-FM sind es alles Eingänge!

Ich geh dann jetzt noch mal kurz (online) schoppen ...

Danke und Gruß,
Mirko
Raspberry Pi 2
HM485-LAN, HMW-Sen-SC-12-DR, HMW-IO-12-Sw14-DR, HMW-Sen-SC-12-FM, 4x HMW-LC-Sw2-DR (in Planung: EIB/KNX-Lan-Gateway)
Lichtsteuerung, Anwesenheitserkennung, Alarmmeldung

Thorsten Pferdekaemper

Zitat von: Ralf9 am 24 Oktober 2015, 16:48:54Ihn hindert daran, daß dies ein Modul für Schaltzustände und Fensterkontakte ist und nur Eingänge hat..
Ok, da habe ich nicht so genau hingesehen. Ich hatte nicht erwartet, dass jemand eine Frage zum HMW-IO-12-FM stellt und dann mit dem HMW-Sen-SC-12-FM ankommt.

Zitat von: Ralf9 am 24 Oktober 2015, 17:46:55Ja, der HMW_IO_4_FM würde auch gehen. Er müsste von FHEM eigentlich auch unterstützt werden. Falls er noch nicht unterstützt wird, dürfte die Anpassung, wie Thorsten auch schon geschrieben hat, kein großes Problem sein.
Ja, genau. Seit einer Weile werden prinzipiell alle Devices unterstützt. Wenn eins nicht richtig funktioniert, dann ist das ein Bug und ich werde versuchen, das zu korrigieren. (Ohne Anerkennung einer Rechtspflicht...)
Es wäre nur gut, wenn es dazu dann einen eigenen Thread im Forum gäbe. Wenn alles in einen einzelnen Thread gematscht wird, dann wird's unübersichtlich.

Gruß,
   Thorsten
FUIP

Thorsten Pferdekaemper

Zitat von: cerberus am 24 Oktober 2015, 16:52:01
Hallo  Thorsten, ja ich meine in erster Linie dimmbare Retrofit-Leuchtmittel mit 230 Volt (E14/E27/GU10/G9) welche gegen die vorhandenen Halogen oder Sparlampen ersetzt werden. Wie gesagt der HMW_LC_Dim1L_DR hat eine Ausgangsbelastbarkeit von 40–200 VA, wobei ich die 40 VA nicht erreichen werde.
Ok, so ein Teil könnten vielleicht einige brauchen. Vielleicht wäre es interessant, so ein Teil zu bauen. Allerdings macht man dann wieder mit 230V rum, was rechtlich bedenklich sein könnte. (...und auch an und für sich gefährlich.) Wenn es irgendein Bauteil gibt, dass diese Lampen dimmen kann und es einen PWM. I2C, SPI oder sonstigen Eingang hat, dann müsste man relativ einfach ein Homematic-Wired-kompatibles Teil dafür bauen können. 
Andererseits wird das Dimmen dieser Retrofit-Lampen immer ein Kompromiss sein. Die Teile müssen halt immer aus den 230V Wechselstrom irgend etwas machen, was die verbauten LEDs verdauen können. Ich verstehe nicht ganz, wie man das überhaupt dimmbar hinbekommt. Besser sind eigentlich Lösungen, bei denen man tatsächlich die LED selbst per PWM oder (noch besser) steuerbare Konstanstromquelle steuern kann. Dummerweise sind solche Systeme noch nicht so verbreitet. Ich vermute mal, dass das daran liegt, dass man nicht einfach die Birne austauschen kann. Wahrscheinlich wäre es schon möglich, entsprechende Leuchtmittel herzustellen, aber es wäre auch recht gefährlich, da viele Leute wohl die Dinger ohne nachzudenken in bestehende Fassungen setzen...
Gruß,
   Thorsten
FUIP

Thorsten Pferdekaemper

Hi,
ich habe gerade die Version 0.7.26 im dev-Branch eingecheckt. Ich denke, dass ich mindestens eine interessante Neuerung dabei habe.

  • Beim Anlegen eines neuen Devices und beim "get config" wird jetzt automatisch die Zentralenadresse ins EEPROM geschrieben. Ich denke, dass das zur Folge hat, dass "logging"-Nachrichten an die Zentrale geschickt werden und nicht per Broadcast. Das bedeutet, dass diese Nachrichten bis zu dreimal wiederholt werden. Dadurch wird die Anzeige des Gerätezustands zuverlässiger.
  • Es gibt jetzt ein Reading "R-central_address", welches die Zentralenadresse enthält. (Genau genommen gibt es da noch ein paar kleine Ungereimtheiten. Spätestens nach dem zweiten get config sollte sie aber stimmen.)
  • Ein set...reset macht jetzt wirklich einen kompletten Factory-Reset. Dabei wird das komplette EEPROM mit 0xFF überschrieben. Vorher wurde z.B. die Zentralenadresse nicht gelöscht.
  • Man kann jetzt auch "hidden" Parameter setzen. (Wenn man weiß wie...)
  • Der ganze Kram rund um's "WaitForConfig" ist jetzt aufgeräumter.

Ein nicht beabsichtigter Effekt ist, dass plötzlich das Discovery funktioniert, zumindest bei mir. Ich weiß auch nicht, warum. Kann das vielleicht jemand ausprobieren?

Jetzt noch ein Punkt, zu dem ich gerne Meinungen hätte:
Bei den Homematic-Wired Geräten kann man die Konfiguration nur über die Felder über dem Geräte-Detailbild machen. Meiner Meinung nach ist das nicht sehr "FHEM-like". Homematic-Funk ist da ganz anders. Meiner Meinung nach sollten eigentlich alle Einstellungen als Readings auftauchen. Hat dazu jemand eine Meinung?

Gruß,
   Thorsten
FUIP

Thorsten Pferdekaemper

Hi,
und wieder eine neue Version im dev-Branch. Jetzt sind wir bei 0.7.27:

  • Es gibt jetzt ein Attribut autoReadConfig. Es kann zwei Werte annehmen: "atstartup" und "always". Damit kann man steuern, wann die Konfiguration aus dem Device (EEPROM) gelesen wird: Bei "atstartup" wird die Konfiguration nur am "Anfang" gelesen, also wenn FHEM gestartet wird oder wenn das Device angelegt wird. Bei "always" passiert das auch, wenn das Device ein "RESPONSE TIMEOUT" hatte. D.h. "always" ist das bisherige Verhalten.
    In jedem Fall kann man das Lesen der Konfiguration per "get ... config all" manuell anstoßen.
    Auch wenn autoReadConfig auf "atstartup" steht, versucht das System endlos, die Konfiguration einzulesen. D.h. man sollte nicht funktionierende oder nicht mehr existierende Geräte immer noch aus FHEM löschen.
    Der Default ist "atstartup". Das ist eine Änderung zum derzeitigen Verhalten, aber ich halte es dennoch für sinnvoll.
    Das Attribut autoReadConfig gibt es für HM485-Devices aber auch für HM485_LAN. Falls ein Device (HM485) das Attribut nicht gesetzt hat, dann wird der Wert aus dem IO-Device (HM485_LAN) geholt. Damit kann man sich sozusagen das Verhalten für alle Devices vordefinieren.

  • CONFIG_STATUS ist jetzt kein Internal mehr, sondern ein echtes Reading. Es hat jetzt den Namen "configStatus". Man kann sich jetzt z.B. ein NOTIFY darauf setzen, falls man etwas erst machen will, wenn es auf OK steht. Außerdem kann man sich einfach per "attr ... stateFormat configStatus state" den Config Status auf die Übersicht basteln.

  • Alle Reading-Updates passieren jetzt asynchron. Dadurch kommen die Events für z.B. state und configStatus jetzt richtig. Außerdem funktioniert das automatische Update der Ansicht im UI.

  • Es ist jetzt schwieriger, die Einstellungen für ein Device zu ändern, das nicht "configStatus OK" hat. Zumindest sind die Eingabefelder dicht und der "Save Config" button (der HMW-spezifische) funktioniert dann nicht. So lange die Konfiguration aus dem Geräte-EEPROM und FHEM nicht synchronisiert ist, kann das ansonsten Probleme bereiten.
Gruß,
   Thorsten
FUIP

mago0211

Hallo Thorsten,

klasse das du an den Modulen weiterarbeitest. Leider habe ich derzeit überhaupt keine Zeit die neue Version zu Testen. Ich hoffe spätestens Weihnachten schaffe ich es endlich wieder.


Gruß
Markus

Thorsten Pferdekaemper

Zitat von: mago0211 am 01 November 2015, 13:53:26klasse das du an den Modulen weiterarbeitest. Leider habe ich derzeit überhaupt keine Zeit die neue Version zu Testen. Ich hoffe spätestens Weihnachten schaffe ich es endlich wieder.
Trotzdem Danke für die positive Rückmeldung!
FUIP

pula

Hallo,

super, vielen Dank!
Da Arduinos bei meinen Tastern leider immer wieder falsche Tastendrucke gemeldet haben, habe ich mir heute zwei HMW-Sen-SC-12-FM gekauft.
Einer funktioniert toll am HM-Lan-Gateway, der andere wird noch nicht erkannt, ich denke, da muß doch ein Busabschluß-Widerstand ran...

Frage zum derzeitigen Status: Ich habe an den HMW-Sen-SC-12-FM Taster hängen. Gibt es derzeit schon die Möglichkeit,  Long-Presses auszuwerten?

Cheers,

Pula
fhem (debian auf proxmox), HM-LAN und wired, MySensors, FritzBoxes, Kodi, vdr, Onkyo, squeezeplayers, nanoCUL, wifilight (Ethernet-Bridge), Heizungssteuerung (python/vncdotool), doorpi, ESP/Arduinos/MQTT, Alexa, HomeConnect, Sonoff/Tasmota, espRGBWW, esphome, Telegram

cjung

Könnte man die stable version mal in den normalen Updateprozess packen?
Ich habe die jeweiligen stable Versionen jetzt seit ca 6 Monaten erfolgreich im Einsatz, aus meiner Sicht sind sie reif für den normalen Updateprozess ?

Viele Grüße
christoph
Raspberry Pi 2 B
Funk: HM_CFG_USB2, HM-CFG-LAN 8*HM_CC_RT_DN, 3*HM-SEC-SD, 3*HM_TC_IT_WM_W_EU, 1*HM-LC-Dim1TPBU-FM,5*HM-SEC-SC-2, 1*HM-SEC-SCo
Wired: HMW: CFG-LAN, 8*LC_Bl1_DR, LC_Dim1L_DR

Jojo11

Vielen Dank für das update! Werde ich gleich morgen testen.

schöne Grüße
Jo


Ralf9

Zitat von: pula am 06 November 2015, 21:03:13
Da Arduinos bei meinen Tastern leider immer wieder falsche Tastendrucke gemeldet haben,
ich habe mir ein HM-Homebrew Modul nachgebaut
http://www.fhemwiki.de/wiki/HomeMatic_Wired
http://forum.fhem.de/index.php/topic,22952.html
und so erweitert und modifiziert, daß es für mich passt.
Ich konnte bis jetzt bei den sensoren und bei den keys keine falsche Tastendrücke oder Schaltzustände feststellen.

Zitat von: pula am 06 November 2015, 21:03:13
Frage zum derzeitigen Status: Ich habe an den HMW-Sen-SC-12-FM Taster hängen. Gibt es derzeit schon die Möglichkeit,  Long-Presses auszuwerten?

Das HMW-Sen-SC-12-FM ist ein Modul für Schaltzustände, es kann keine short- und long-Presses.
Für short- und long-Presses gibt es u.a. die folgenden Module  HMW-IO-12-FM  HMW-LC-Sw2-DR   HMW-IO-12-SW7-DR
oder Du baust Dir ein HM-Homebrew Modul das short- und long-Presses kann.

Module die short- und long-Presses können haben auch den Vorteil, daß sie peering können.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

pula

Hi Ralf9,

vielen Dank für die Erklärung!
Ganz schön teuer...

Kleine Zusastzfrage:

Habe jetzt zwei von den HMW-Sen-SC-12-FM gekauft und den Lan-Adapter.
Verkabelt habe ich das so, daß die busleitungen vom Lan-Adapter zum ersten HMW gehen und dann weiter zum zweiten HMW.
Leider wird nur der erste erkannt.
Kann das sein, daß das am fehlenden Abschlußwiderstand liegt? Die komponenten liegen direkt nebeneinander auf der Hutschiene...

Cheers,

Pula
fhem (debian auf proxmox), HM-LAN und wired, MySensors, FritzBoxes, Kodi, vdr, Onkyo, squeezeplayers, nanoCUL, wifilight (Ethernet-Bridge), Heizungssteuerung (python/vncdotool), doorpi, ESP/Arduinos/MQTT, Alexa, HomeConnect, Sonoff/Tasmota, espRGBWW, esphome, Telegram

Ralf9

Zitat von: pula am 08 November 2015, 20:47:58
Kann das sein, daß das am fehlenden Abschlußwiderstand liegt? Die komponenten liegen direkt nebeneinander auf der Hutschiene...

Ganz ausschließen wird man es nicht können. Der Abschlußwiderstand sorgt für definierte Spannungspegel auf dem Bus.
Du kannst für den Abschlußwiderstand auch 3 Widerstände verwenden:
http://homematic-forum.de/forum/viewtopic.php?f=31&t=15128&p=119896

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7