Homematic wired

Thorsten Pferdekaemper · 03 September 2015, 21:47:28

Hi,
sorry, dass ich so lange nichts von mir habe hören lassen. Ich musste im Urlaub lernen, dass Wasser-Rutschbahnen gefährlich sind. Mann kann sich eine verdammt üble und hartnäckige Erkältung holen.

Ich hatte (außer den anderen Sachen in diesem Thread) erst einmal etwas aufräumen müssen, da ich auch noch eine Änderung von honk im Eingang hatte. Da ich außerdem die Version 0.7.21 für relativ stabil halte (ich weiß, ein paar Kleinigkeiten sind da noch), habe ich sie nach master übernommen. Jedenfalls ist 0.7.21 besser als 0.6.3.
Die neue dev-Version (0.7.22) hat ein paar Verbesserungen beim Peering. Wesentlich dabei ist, dass man jetzt die PeerList auch in Aktor-Kanälen hat und ein Peering auch vom Aktor aus löschen kann. (Setzen geht nach wie vor nur vom Sensor aus.) Danke an honk für die Änderung.

Gruß,
Thorsten

stephan-221 · 03 September 2015, 21:50:29

Hallo Thorsten,

Dann erstmal gute Besserung!

Jetzt werde ich mal produktiv von 0.6.3 auf 0.7.21 wechseln

Viele Grüße
Stephan

Thorsten Pferdekaemper · 03 September 2015, 22:39:20

Hi,

Zitat von: geri am 03 September 2015, 10:29:33ich habe dieses modul auch schon länger im einsatz und hat eigentlich immer funktiniert. derzeit verwende ich die dev 0.7.21, dort funktioniert auch alles. das state ist "sensor_open" bzw. "sensor_closed".

Auch wenn das mit dem state so stimmt, würde ich dennoch empfehlen, für notifys oder ähnliche Sachen nicht das Reading state, sondern das Reading sensor zu verwenden. Laut Gerätebeschreibung heißt das Reading "sensor". Die FHEM-Integration ermittelt daraus dann halt ein state, aber nur, wenn "sensor" auch im letzten Frame vorkommt, der vom Gerät für den entsprechenden Kanal geschickt wird. Anders gesagt: "sensor" ist sicherer.
Allgemein gesagt: Wenn es ein anderes Reading als "state" für einen Kanal gibt, das passen erscheint, dann sollte man nicht "state" benutzen.
Nochmal zur Version: Die 0.7.21 ist jetzt im master-Branch. Ich halte sie sogar für stabiler als die 0.6.3.

Zitat von: BrainHunter am 03 September 2015, 13:15:08
Das Problem im HM485d ist das die Serielle Schnittstelle vor dem fork geöffnet wird. Das Fork Kopiert jetzt den Prozess mitsammt der Datei Deskriptoren und dann wird der Prarent beendet. Beim Beenden wird jetzt noch versucht die Schnittstelle wieder zurückzustellen. (Macht das Perl automatisch? Oder kommt das aus der Implementierung vom HM485d/FHEM/...)
Ich denke wir haben hier im Prinzip 2 Möglichkeiten:
1. Das Fork an den anfang stellen.
2. Die Datei Deskriptoren der Serielle Schnittstelle (und evtl. auch des Netzwerk Socket) im Parent schließen bevor exit() aufgerufen wird.
Ersteres sollte einfacher sein

Ich habe das jetzt mit Version 0.7.23 geändert. Der fork kommt jetzt zuerst. Es wäre toll, wenn Du das mal ausprobieren könntest.
Die Änderung ist in ServerTools.pm. Inzwischen gehört diese Datei nach FHEM/lib/HM485/HM485d. Vorher war sie mal direkt im Verzeichnis FHEM. Dasselbe gilt für DevIo485.pm.
Gruß,
Thorsten

BrainHunter · 05 September 2015, 11:03:11

Zitat von: Thorsten Pferdekaemper am 03 September 2015, 22:39:20
Ich habe das jetzt mit Version 0.7.23 geändert. Der fork kommt jetzt zuerst. Es wäre toll, wenn Du das mal ausprobieren könntest.
Die Änderung ist in ServerTools.pm. Inzwischen gehört diese Datei nach FHEM/lib/HM485/HM485d. Vorher war sie mal direkt im Verzeichnis FHEM. Dasselbe gilt für DevIo485.pm.

Habe eben die neue Version gepullt und getestet. Sieht sehr gut aus!
Danke

Thorsten Pferdekaemper · 05 September 2015, 12:17:23

Zitat von: BrainHunter am 05 September 2015, 11:03:11
Habe eben die neue Version gepullt und getestet. Sieht sehr gut aus!

Danke für die Rückmeldung!
Gruß,
Thorsten

holle75 · 11 September 2015, 11:47:18

Hello, wollte noch mal kurz für Nachlesende oder ähnlich gebeutelte die Auflösung meiner Odyssee (siehe http://forum.fhem.de/index.php/topic,10607.msg309346.html#msg309346 ) runterschreiben.

Final hat Dirk herausgefunden, dass die meisten Receiver-Chips, egal ob USB oder Netzwerk, auf der Hardware um sich mit dem Bus zu verbinden max 15V Spannung aushalten. Der von EQ3 vertriebene Überspannungsschutz wirkt wohl erst ab 15V (und in der EQ3 Hardware sind Chips bis 60V verbaut).

Nachdem Dirk auf meiner Hardware einen 60V Chip verbaut hat läuft die Nummer! Viele, viele Steine sind da von meinen Schultern gefallen!

Da mein Bus im Moment ca. 300 Meter lang ist liegt die Vermutung nahe, dass die "Überspannungen" vielleicht etwas mit der Länge des Buses zu tun haben könnten.

Das sind Vermutungen, aber vielleicht für den ein oder anderen ein Ansatz für die Suche bei ähnlichen Problemen.

Nochmals vielen Dank an Dirk für die Detektivarbeit.

Grüße

H.

EDIT 29.11.2015 .... es gab auch nach den Chipumbauten noch Probleme mit Spannungsspitzen. Final habe ich jetzt am Ende eines jeden Stranges (jeweils ca. 100m) einen "Abschluss"-widerstand hängen (ja, wirklich am ENDE des Buses). Bis jetzt geht es. Ob das Sinn macht (nach Definition von EQ3 nicht wirklich, da Widerstand irgendwo im Bus sein kann) ist mir egal, solange es die Probleme gelöst hat.

Thorsten Pferdekaemper · 11 September 2015, 11:52:59

Zitat von: holle75 am 11 September 2015, 11:47:18
Nachdem Dirk auf meiner Hardware einen 60V Chip verbaut hat läuft die Nummer!

Hast Du auch schon eine Erklaerung, wo eine Spannung von > 15V herkommt?
Gruss,
Thorsten

holle75 · 11 September 2015, 11:55:02

Hey Thorsten, nein, bis jetzt noch nicht. Da muß ich bei Gelegenheit nochmal ran. Logisch ist es imer noch nicht

Dirk · 11 September 2015, 11:56:31

Ich vermute das sind / waren Potentialunterschiede auf Grund der längeren Leitung.
Daher immer GND, also Masse oder auch Minus, aller Module und auch des Interfaces zusammen verbinden.
Und natürlich bei Arbeiten am Bus dessen Versorgungsspannung abschalten.

Viele Grüße
Dirk

holle75 · 11 September 2015, 12:00:38

Hallo Dirk, schön du da

blöde Frage: könnte es denn überhaupt ohne dass alle Module mit Minus verbunden sind laufen? Ich versuche mir gerade einen Aufbau vorzustellen, wo das nicht der Fall wäre.

Dirk · 11 September 2015, 12:09:20

Ja. RS485 überträgt die Daten differenziell (symetrisch) über A und B. Eigentlich reicht es aus A und B zu verbinden. Aber, um Potentialunterschiede auszugleichen sollte man auch Masse mit verbinden.
Wenn die Potentialunterschiede zu groß werden, was ich in deinem Fall vermute, dann kann das ebend auch die Tranceiver beschädigen.

Wen das technische zu RS485 interessiert: https://de.wikipedia.org/wiki/EIA-485

Viele Grüße
Dirk

holle75 · 11 September 2015, 12:24:36

Jetzt muß ich noch eine kleine Verständnisfrage stellen: Ich benutze grünes, 4 adriges Bus-Kabel (rot für +, schwarz für minus(GND), weiss für A, gelb für B) und schleife alle Module mit allen 4 Kabeln durch. Zusätzlich lege ich das Schirmungskabel immer am Anfang einer Strecke mit auf GND auf (das Ende ist somit nirgendwo verbunden, läuft aber bis zum "entfernten" Modul mit im Kabel).

Das ist die "Minus überall aufgelegt"-Verteilung die du meinst, richtig?

viele Grüße

H.

Dirk · 11 September 2015, 23:02:51

ZitatDas ist die "Minus überall aufgelegt"-Verteilung die du meinst, richtig?

Der Schirm ist da egal.

Zitatschwarz für minus(GND)

Genau das sollte durchgehend verbunden sein.

holle75 · 12 September 2015, 15:19:02

Danke Dirk.

Hallo Alle, ich habe jetzt mal einen Fensterkontakt (auf/zu) auf einen Schaltereingang eines meiner 12/7 Module gelegt. Den input_type des Channels auf "switch" gestellt und hatte eigentlich gehofft zwei states dadurch zu erhalten. Ich bekomme aber, wie auch bei input_type "pushbutton" einen hochzählenden press_short_xx als state. Was sollte der input_type "switch" in der Theorie bezwecken und hat jemand eine Idee, wie man einen definitiven state (zu/auf) erhalten könnte?

Grüße

H.

EDIT: Oh Eigentor, erst lesen dann Ideen haben. Laut ELV: Hinweis: Für die Zustandsauswertung von Schaltkontakten ist dieses Modul nicht geeignet

EDIT2: Jemand eine Idee, mit welchem Hardware-Sensor man das für EINEN Fensterkontakt an fhem günstig umsetzen könnte? Das 70,-Modul mit 12 Eingängen von ELV ist wohl overdone

holle75 · 13 September 2015, 11:05:04

Ich schon wieder. Dachte ja jetzt läuft alles.

Tut es auch, aber ca. alle 10 Minuten habe ich einen Disconnect/reconnect zum HM485d im Log. Der dauert nur ein paar Millisekunden, aber .....
Jemand eine Idee woher das kommen mag?

Log mit Verbose 3:

Code Auswählen

2015.09.13 10:50:33.107 1: 192.168.10.27:5000 disconnected, waiting to reappear (SERIAL)
2015.09.13 10:50:33.109 2: HM485d: DISCONNECTED
2015.09.13 10:50:33.112 2: HM485d: SERIAL connected to device 192.168.10.27:5000
2015.09.13 10:50:33.113 2: HM485d: RECONNECTED

2015.09.13 11:00:37.519 1: 192.168.10.27:5000 disconnected, waiting to reappear (SERIAL)
2015.09.13 11:00:37.520 2: HM485d: DISCONNECTED
2015.09.13 11:00:37.524 2: HM485d: SERIAL connected to device 192.168.10.27:5000
2015.09.13 11:00:37.525 2: HM485d: RECONNECTED