Welche Hardware für Eingänge nutzen mit proaktiver Meldung?

[duu75]

Ich bin auf der Suche nach einer drahtgebundenen Hardware für FHEM, bei der ich Eingänge open/close Status übermittelt bekomme.

Zur Zeit nutze ich den Pollin AVR-NET-IO mit ethersex / ECMD.
Ich frage die analogen bzw. digitalen Eingänge des AVR mit einem AT alle 10 Sekunden ab um den Status zu ermitteln um mit notify auszuwerten.

Wenn allerdings zwischen den Abfrageintervallen (10 Sek.) eine Zustandsänderung passiert und wieder in den alten Zustand zurückkehrt, sieht es eben für FHEM so aus als wäre da nix gewesen!
Der Eingang muss also mind. länger als 10 Sek. open oder closed sein.

Welche Hardware übermittelt per TCP o.ä. proaktiv bei Eingangsstatusänderung an FHEM die Daten ohne das ich Pollen muss aus FHEM heraus?

Also eigtl. sowas wie das FS S4M Modul nur eben ohne Funk!

Geht sowas mit einem Homematic HMW-Sen-SC-12-DR oder HMW-Sen-SC-12-FM o.ä. und RS485 USB-Adapter oder so?

Grund gegen Funkschnittstelle ist eigtl. nur ein Sicherheitsgrund, da hier Tür-/Fensterkontakte, Bewegungsmelder überwacht werden sollen für Alarmanlage.
Und hier will ich sichergehen, dass man nicht mit einem Störsender das Netz platt macht und so nicht mehr auslösen kann.

Gruß
Dirk

[duu75]

Gar keiner eine Idee?
Das Problem bzw. Anforderung kann ich doch nicht nur alleine haben. 

[justme1968]

wenn es dir mehr darauf ankommt das keine event verloren gehen und nicht so sehr auf das intervall schaut dir mal 1-wire mit den DS2406 oder DS2408 bausteinen an. die erkennen selbständig die flanken und speichern sie bis sie zurück gesetzt werden. du kannst also auch sehr kurze einmalige ereignisse unabhängig von pooling intervall erfassen.

gruss
  andre

[kpwg]

Gar keiner eine Idee?
Das Problem bzw. Anforderung kann ich doch nicht nur alleine haben. 

Hast Du auch nicht, nur warst Du einen Tag zu früh 

Seit 16.3. gibt es ein neues ECMD Modul zum testen.
http://forum.fhem.de/index.php/topic,21515.0.html

und
http://forum.fhem.de/index.php/topic,21636.0.html

Damit sollte das nun gehen. Die genaue Syntax für ECMD read erkunde ich die nächsten Tage. Vermutlich geht es nicht ohne control6.

Viele Grüße, Ricardo

[duu75]

OK.

Habe mal die beiden aufgeführten Threats gelesen und versucht zu verstehen mit dem expected etc. aber nicht so richtig verstanden.

Heisst das auch ich darf jetzt aktuell kein UPDATE von FHEM machen, sonst geht meine alte Konfiguration mit dem AVR gar nicht mehr und müsste auf irgdnwelche neue Syntax umgeschrieben werden, die ich bisher aber noch nicht durchschaue? 

[ntruchsess]

Du könntest einen Arduino mit Firmata verwenden.
Der sendet Änderungen an digitalen Eingängen immer dann, wenn Sie passieren (mit FRM bzw. FRM_IN). Wenn der Arduino außer den Digitalen Eingängen sonst nix machen soll, dann liegt die Auflösung (bzw. die Erkennbarkeit von kurzen Impulsen) im ms-Bereich (Bei gleichzeitiger Verwendung von anderen Firmata-features hängt das davon ab, ob bzw. wie lange diese den µC blockieren können, liegt aber auch bei gleichzeitiger Verwendung von 1-Wire in der Größenordnung von 100ms. Bei hoher Impulsfrequenz wird das Ganze natürlich durch die verfügbare Bandbreite eingebremst.

EDIT:
Das schöne daran ist: mit ein bischen Basteln läuft FRM + Firmata auch auf Deinem AVR-NetIO

Gruß,

Norbert

[kpwg]

Habe mal die beiden aufgeführten Threats gelesen und versucht zu verstehen mit dem expected etc. aber nicht so richtig verstanden.

"expect" heißt erwarten. Du schaust (zB im ECMDDevice mit "log traffic 0"), was an Daten zurück gemeldet wird aus baust damit das, was erwartet wird. Ich stand noch vor wenigen Wochen genau wie Du vor dem Problem. Bin eher Handwerker und kann löten, aber nix coden  Da hilft nur viel Perl lesen und anhand kleiner Beispiele die Eigenarten zu verstehen. Mir hat das wiki sehr geholfen.

Heisst das auch ich darf jetzt aktuell kein UPDATE von FHEM machen, sonst geht meine alte Konfiguration mit dem AVR gar nicht mehr und müsste auf irgdnwelche neue Syntax umgeschrieben werden, die ich bisher aber noch nicht durchschaue? 

Noch ist es nicht so weit, jedoch wird mit dem neuen ECMD und ECMDDevice vorhandener Code aus classdefs nur noch eingeschränkt funktionieren.

Vorschlag: poste Deine Classdef's und wir schauen uns das gemeinsam an- da lernen wir beide was. Vielleicht schreibt noch wer mit Zugang zum wiki die seite um. So hast du dann zum Update die neuen classdefs in der Schublade.

Viele Grüße, Ricardo

[Klaus0815]

Hallo Dirk,

Du kannst bei den Net-IOs unter Ethersex direkt "watch IO changes " nutzen.
Ist lange her, müsste schauen wie genau der Befehl aussieht, aber es geht definitiv, läuft bei mir hier seit Jahren so.

schau mal hier diesen Thread an:

http://forum.fhem.de/index.php/topic,16618.0.html

Grüße

Klaus

[kpwg]

... läuft bei mir hier seit Jahren so.

schau mal hier diesen Thread an:

http://forum.fhem.de/index.php/topic,16618.0.html

Hallo Klaus,

bitte nicht böse sein, aber genau diese Threads mit den kaum umschriebenen Workarounds "bescheren" nur neue Bastellösungen. Das Modul selbst, was gerade einen großen Schritt nach vorne macht, bleibt dabei auf der Strecke. Klar gibt es für alles eine Lösung auch außerhalb von FHEM, nur wo ist da der Sinn? Es gibt aktuell DIE Chance, ECMD den Anforderungen gerechter werden zu lassen!

Die Statistik sagt, das über 250 Installationen aktiv ECMD nutzen- verglichen mit allen anderen Modulen scheint es hier am wenigsten Gesprächsstoff sowie kaum Doku zu geben. Sehr schade- ist doch Ethersex im handumdrehen compiliert (ohne Programmierkenntnisse!), überdurchschnittlich stabil und extrem flexibel. Ich würde mir wünschen, mehr Beispielkonfigurationen zu sehen...

Viele Grüße, Ricardo

ps: das die Netzwerkverbindung gelegentlich "einpennt", ist allein ein Konstruktionsmangel im AVR Net-IO! 

[Klaus0815]

Hallo Ricardo,

ich bin überhaupt nicht böse, im Gegenteil, finde es gut wenn hier auf Ethersex eingegangen wird, es sind auch sicher weit mehr als 250 Installationen am laufen.

Ich sehe  2 Probleme / Thematiken:
- Bin nicht der Ethersex-Experte, aber ich glaube es ist nicht möglich, über welches FHEM-Modul auch immer auf Portänderungen zu reagieren, solange Ethersex nicht von sich aus was schickt, und das geht z.B. sehr gut über "Watch IO Changes and React" o.ä., jegliches periodische Abfragen widerspricht dem Ansatz einer ereignisgesteuerten Aktion

- Wie Du sagst ist Ethersex eher schlecht dokumentiert (Umzug auf neuen Server usw), ganz so einfach kompiliert ist es leider auch nicht (Bootloader, ... , wir sind hier im Anfängerforum, ich habe vor 2 Jahren auch als reiner Windows-Nutzer angefangen)  Und FHEM kann dermaßen viel, das sich Anfänger schwer tun, was sich aber leider bei dem gewaltigen Funktionsumfang auch nicht ändern lässt.

Ich habe hier 3 Ethersex am laufen, diese messen, steuern, regeln, ich denke es gibt kaum was günstigeres das dermaßen universell einsetzbar ist, aber der Laie sieht erst mal die "Großbaustelle FHEM", dann noch eine 2. Baustelle Ethersex aufmachen ? (Ich musste zugegeben Deine beiden Links mehrfach lesen um zu verstehen um was es geht, das ist einfach schon 3 Schritte weiter als der normale Anwender ist)

Vielleicht fehlt es hier einfach mal an guten, einfachen Beispielen ?  Für die einen ist FHEM / Ethersex usw. ein Hobby, der andere will einfach endlich seine Gartenpumpe abhängig vom Sonnenstand schalten, ohne alle Details zu verstehen, es muss funktionieren

Wie wäre es mit einem Ethersex-Forum hier ?

Viele Grüße

Klaus

[kpwg]

ich bin überhaupt nicht böse, im Gegenteil, finde es gut wenn hier auf Ethersex eingegangen wird, es sind auch sicher weit mehr als 250 Installationen am laufen.

Hallo Klaus, danke für's "Verstehen". Es ist immer schwierig, Kritik zu schreiben, die man nicht in den falschen Hals bekommt.

Ich sehe  2 Probleme / Thematiken:
- Bin nicht der Ethersex-Experte, aber ich glaube es ist nicht möglich, über welches FHEM-Modul auch immer auf Portänderungen zu reagieren, solange Ethersex nicht von sich aus was schickt, und das geht z.B. sehr gut über "Watch IO Changes and React" o.ä., jegliches periodische Abfragen widerspricht dem Ansatz einer ereignisgesteuerten Aktion

Das sehe ich genauso: pollen macht keinen sinn, weil das nicht wirklich zeitnah ist. Außerdem habe ich die Befürchtung, das man den IP-Stack schnell an die Wand fährt bzw unnötig belastet. Kannst du bitte umschreiben, wie "Watch IO Changes and React" auf ethersex-Seite programmiertechnisch aussieht? Ist das in control6 oder im menuconfig?

- Wie Du sagst ist Ethersex eher schlecht dokumentiert (Umzug auf neuen Server usw), ganz so einfach kompiliert ist es leider auch nicht (Bootloader, ... , wir sind hier im Anfängerforum, ich habe vor 2 Jahren auch als reiner Windows-Nutzer angefangen)  Und FHEM kann dermaßen viel, das sich Anfänger schwer tun, was sich aber leider bei dem gewaltigen Funktionsumfang auch nicht ändern lässt.

Naja, es ist nicht wirklich schlecht dokumentiert, nur nicht zentral. Kein einheitliches und gepflegtes Wiki; überall verstreut ein wenig Info. Das hilft uns als Einsteiger nicht unbedingt weiter. Wenn es einmal läuft, sind die Fortschritte allerdings groß. Ich habe gestaunt, in wie wenig Zeit ich letztlich doch lauffähige Images hatte. Ich bin nur wenig mit Linux vorbelastet; komme auch von Windows.

Ich habe hier 3 Ethersex am laufen, diese messen, steuern, regeln, ich denke es gibt kaum was günstigeres das dermaßen universell einsetzbar ist, aber der Laie sieht erst mal die "Großbaustelle FHEM", dann noch eine 2. Baustelle Ethersex aufmachen ? (Ich musste zugegeben Deine beiden Links mehrfach lesen um zu verstehen um was es geht, das ist einfach schon 3 Schritte weiter als der normale Anwender ist)

Bei mir läuft erst ein E6-System produktiv; weitere sind aber in Planung bzw. in Arbeit (Zutaten sammeln, ...). Zum Testen habe ich stets ein Atmel STK200 zur Hand. Ich habe mit Ethersex angefangen und hatte zu dem Zeitpunkt noch gar kein FHEM laufen (nur eingeplant). War aus jetziger Sicht gut so, denn zwei komplexe Baustellen sind nicht förderlich. Wenn Du meine ersten Beiträge liest wirst Du sehen, das ich mich ganz schön dumm angestellt habe. Ich wusste nichts von classdef's, readings und eine "curly bracket" fand ich eher lustig als nützlich. Nun verstehe ich (meistens) classdef's, baue sogar selbst welche und meine, das ich nun dem Forum auch etwas Sinnvolles wiedergeben muss. Perl ist nicht einfach; bin eher der Handwerker als Programmierer. 

Vielleicht fehlt es hier einfach mal an guten, einfachen Beispielen ?  Für die einen ist FHEM / Ethersex usw. ein Hobby, der andere will einfach endlich seine Gartenpumpe abhängig vom Sonnenstand schalten, ohne alle Details zu verstehen, es muss funktionieren

Diese Beispiele würde ich mir hier so sehr wünschen. Es sind oft die Kleinigkeiten, die man sich abgucken und für eigene Ideen zurecht stricken kann. Es ist sehr individuell und nicht so schön einfach und dokumentiert, wie zB. FS20. Dafür viel adaptiver und vielseitiger. Zudem kommt die hohe Zuverlässigkeit und der geringe Preis, wenn man nicht jeden Widerstand kaufen muss. Und wenn's billig sein soll => Pollin NetIO oder China-Arduino kaufen und flashen.

Wie wäre es mit einem Ethersex-Forum hier ?

Aus meiner Sicht beschränkt sich das auf <10 Aktivisten. Wir haben alle unsere Gründe und speziellen Anwendungen für Ethersex. Das würde wohl nur Sinn machen, wenn die Beteiligung der Nutzer wesentlich größer ist. Ich bin realistisch: das wird aus heutiger Sicht nichts. Unterstützen würde ich sowas dennoch gerne.

Viele Grüße, Ricardo