Fenster/Tür Status Sensor mit Asksin Lib?

[papa]

Könnte vielleicht das selbe Problem wie hier sein

https://forum.fhem.de/index.php/topic,57486.msg1196038.html#msg1196038

[Tobias]

ich bin mir nicht sicher ob es dasselbe problem ist. Das wirft für mien VErständnis aber eine neue Frage auf. Wenn der Pin immer wieder auf LOW gezogen wird, wie wird dann eine Statusänderung erkannt? Wird in der Lib nicht intern mit der PinChangeInterrupt Lib gearbeitet? Dazu muss doch der Pin aber permanent auf INPUT_PULLUP gezogen sein?

Duch das Signal LOW wird der aufgeladene CAP quasi kurzgeschlossen. Dadurch ist er leer und verbindet LOW-Signal mit GND. Das könnte das Problem sein. ICh hatte es nur gut gemeint und extra den 2.2uF als Debouncer eingebaut. Muss ich jetzt eben weglassen.

GRundsätzlich funktioniert alles.
@papa, kannst du Sketch und HM-Modul Erweiterung bei dir im Repo und im FHEM-Repo einchecken?

[papa]

ich bin mir nicht sicher ob es dasselbe problem ist. Das wirft für mien VErständnis aber eine neue Frage auf. Wenn der Pin immer wieder auf LOW gezogen wird, wie wird dann eine Statusänderung erkannt? Wird in der Lib nicht intern mit der PinChangeInterrupt Lib gearbeitet? Dazu muss doch der Pin aber permanent auf INPUT_PULLUP gezogen sein?

Nein - es wird kien Interrupt verwendet, sondern im Sekundentakt gepollt. Dazu wird der Pin auf Eingang gestllt, der Status gelesen und dann wieder auf Output LOW gestellt. Dadurch wird bei dauerhaft auf GND gezogenen Pin kein Stromverbrauch. Aber wie wir jetzt sehen, hat das auch "nette" Nebeneffekte.

Duch das Signal LOW wird der aufgeladene CAP quasi kurzgeschlossen. Dadurch ist er leer und verbindet LOW-Signal mit GND. Das könnte das Problem sein. ICh hatte es nur gut gemeint und extra den 2.2uF als Debouncer eingebaut. Muss ich jetzt eben weglassen.

Das hatte ich auch gleich gedacht, als ich Deine Nachricht gelesen habe. Durch das Pollen gibt es keine Bouncing-Probleme.

GRundsätzlich funktioniert alles.
@papa, kannst du Sketch und HM-Modul Erweiterung bei dir im Repo und im FHEM-Repo einchecken?

Beim mir kann ich das gerne einchecken. Für FHEM nicht.

[Papa Romeo]

Dadurch wird bei dauerhaft auf GND gezogenen Pin kein Stromverbrauch. Aber wie wir jetzt sehen, hat das auch "nette" Nebeneffekte.

... dass, wenn der Pin wieder als Eingang geschaltet wird, der 2.2 uF Kondensator über den Internen Pullup ne entsprechende Zeit zum Laden benötigt, um am Eingang wieder einen Pegel zur Verfügung zu stellen, der als HIGH erkannt wird.

LG
Papa Romeo

[Tobias]

wer kann denn die HM-Modul Erweiterung im FHEM Repo einchecken?

[papa]

Schau mal - das könnte für die Batterievariante interessant sein:

https://github.com/jp112sdl/HB-SCI-x-MSP

[gregorv]

Sorry, wenn ich hier dazwischenkomme. Ich habe nämlich zufällig gesehen, dass hier mein Problem 'gestreift' wird.
In meinem Scetch möchte ich den Status von zwei PINs abfragen, die als PINs in einem TwoStateChannel konfiguriert sind. Ich lese aber immer LOW, selbst wenn der Eingang HIGH sein sollte.
papa hat ja oben die Erklärung dazu geliefert "wird nur im Sekundentakt mal kurz als INPUT geschaltet" und ist sonst OUTPUT, LOW.
Details habe ich im Thread Homematik angegeben  https://forum.fhem.de/index.php/topic,126125.msg1207277.html#msg1207277 .

Die PINS sind Endschalter für eine Markise und der Motor darf nicht darüber hinausfahren. Die Steuerung eine um ein TwoStateChannel erweiterte Rolladensteuerung HM-LC-Bl1-FM.
papa kann folgende Frage vermutlich sofort beantworten:
Kann ich den Status der PINs im Scetch in dem TwoStateChannel abfragen?  - digitalRead() liefert ja LOW, während der PIN ein OUTPUT ist.
Danke,
Gregor

[gregorv]

nach etwas mehr Suche... das Problem existiert ja offenbar nicht mehr.
In der aktuellen AskSinPP lib bleibt ein Eingang dauerhaft INPUT (während der Messung INPUT_PULLUP).
Damit sollte mein Problem gelöst sein, werde ich morgen gleich testen.

[gregorv]

OK, Problem gelöst.
Mit der aktuellen AskSinPP Library liefert digitalRead() jederzeit den realen Status vom Sensor. Und das Problem, was Tobias geschildert hat, hatte ich auch. Bei mir waren es 100nF Kondensatoren, die dazu führten, dass der HIGH Status (trotz eines externen 10K PullUp) nicht mehr gelesen werden konnten. Wenn der PIN auf LOW gezogen wird und nur für die Messung kurzzeitig gelesen wird, reicht die Messzeit nicht aus um einen Entstörkondensator so hoch zu laden, dass ein HIGH gelesen werden kann.
Die jetzige Variante, den PIN auf INPUT zu setzen ist auch aus diesem Grund erheblich sicherer - gar nicht zu reden von Signalen, die aktiv auf HIGH gezogen werden und damit dann einen Kurzschluss (zumindest hohen Strom) erzeugt hatten.

[Tobias]

Hi papa,

ich habe jetzt den Fall, das ich in einer Tür einen normalen Reedkontakt oben angebracht habe. Damit weiss ich ob die Tür auf oder zu ist. Weiterhin habe ich im Türschloss einen Schließkontaktsensor. Damit weiß ich ob die Tür abgeschlossen ist oder nicht.

Nun wollte ich im Sensor, im Channel folgendes machen:

Code Auswählen Erweitern

set <dev> regset msgRhsPosA locked
aber leider gibt es nur vordefinierte formate:

Code Auswählen Erweitern

invalid value. use:closed,noMsg,open,tilted

Irgendeine Idee wie ich die states [open|closed|locked] hinbekomme?

[papa]

Nur mit einen eigenen Gerät.
Siehe https://github.com/pa-pa/AskSinPP/blob/5bc817e1a5341c27434d26d476ed30f69e29fe46/examples/custom/contrib/FHEM/HMConfig_AskSinPPCustom.pm#L337

[Tobias]

Hi papa,
ich denk mir etwas fhem-internes aus. Ich denke an ein Userreading für einen eigenes state. Oder an "stateFormat". An einem Device hängen manchmal fenster und türen zusammen

Ich habe heute meinen zweiten Sensor zusammengebaut, diesmal fest verlötet ohne Steckschuhe damit der Aufbau niedriger wird.
Funktioniert super

Ich habe mal alles hier dokumentiert: https://github.com/tobiasfaust/WindowStatusSensor/tree/master/ATMega328p%20Version

Der sensor wird an 5V angeschlossen und Arduino Mini als auch CC1101 werden durch den externen 3,3V LDO versorgt.