diverse Sensoren an FHEM anbinden OHNE Funk

Begonnen von flipse, 03 Juli 2019, 08:34:32

Vorheriges Thema - Nächstes Thema

flipse

#30
sind die I/Os nicht alle gleich?

habs nun angeschlossen, wie auf der MySensors page. leider immer noch -127

flipse

#31
Zitat von: flipse am 07 Juli 2019, 15:49:34
sind die I/Os nicht alle gleich?

habs nun angeschlossen, wie auf der MySensors page. leider immer noch -127

Ich habe es jetzt auch mal mit dem unveränderten Beispiel von MySensors versucht.
Also bis auf die GW Kommunikation.
Leider immer noch Fehlanzeige. jetzt wird nicht mal mehr der Temperatursensor über Autocreate hinzugefügt.

Ich habe mal ein Debug im SerialMonitor auf die Anzahl der gefundenen Sensoren durchgeführt. Hier wird eine 0 ausgegeben. Anscheinend findet er meinen Sensor nicht.
Verdrahtet ist es jedoch, wie im Beispiel angegeben.

Habe nun auch noch extra einen externen USB Hub mit externer Stromversorgung eingesetzt


Beta-User

Zitat von: flipse am 07 Juli 2019, 14:38:39
ok. habe den nun zwischen gelb und d10 gesetzt.
aber immer noch nur -127.0 als Wert :/
Wie ist denn die Verkabelung jetzt genau?
Das oben beschriebene klingt falsch, das "data"-Kabel (das häufig gelb ist) muß direkt an den IO-Pin (und ja, bzgl. 1-wire sind tatsächlich alle PINs von D2-A7 tauglich, D10 geht daher auch). Der pullup muß aber "zwischen" 5V und "data" (bzw. dem IO-PIN), das klang so, als würdest du die Spannungsversorgung des pullup über einen PIN machen wollen....
Wenn das mit dem korrekt angeschlossenen pullup nicht klappt, hat vermutlich der Sensor selbst einen Hau oder der Widerstandswert paßt nicht (bitte ggf. mal nachmessen).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

flipse

Zitat von: Beta-User am 08 Juli 2019, 07:27:12
Wie ist denn die Verkabelung jetzt genau?
Das oben beschriebene klingt falsch, das "data"-Kabel (das häufig gelb ist) muß direkt an den IO-Pin (und ja, bzgl. 1-wire sind tatsächlich alle PINs von D2-A7 tauglich, D10 geht daher auch). Der pullup muß aber "zwischen" 5V und "data" (bzw. dem IO-PIN), das klang so, als würdest du die Spannungsversorgung des pullup über einen PIN machen wollen....
Wenn das mit dem korrekt angeschlossenen pullup nicht klappt, hat vermutlich der Sensor selbst einen Hau oder der Widerstandswert paßt nicht (bitte ggf. mal nachmessen).

Ja. Die Verdrahtung war falsch.
Ich hatte den Widerstand zwischen Data und dem Pin gesetzt. Es sah für mich irgendwie falsch aus, eine "Brücke" zwischen Data und 5V zu bauen. Aber so hat es dann sofort funktioniert.

Vielen Dank für Deine/Eure Hilfe.
Ich bekomme nun die Kontaktsensoren eingebunden und meine Temperatursensoren. Jetzt "nur" noch den Wasserzähler mit dem DS2423 versuchen und dann kann das Ding produktiv eingesetzt werden.
Bisher alles noch auf dem Schreibtisch.

Jetzt versuche ich erstmal den Code "aufzuräumen" und zu optimieren.

Beta-User

Gut, dass sich das mit der Verkabelung geklärt hat.

Aber wieso willst du für den Wasserzähler extra Hardware nehmen?

Geht zwar vielleicht auch, aber dafür war die Empfehlung, D2/D3 freizuhalten. Diese beiden PINs sind nämlich dahingehend anders, dass die (für den jeweilien PIN direkt eine Aussage treffende) Interrupts liefern, was z.B. für Zählerzwecke recht einfach genutzt werden kann. Basis wäre da dieser Sketch: https://www.mysensors.org/build/pulse_water. Wenn du einen weiteren Zähler haben wolltest: einfach die ISR (Interrupt Service Routine, bei diesem Sketch: "onPulse") doppeln und entsprechend anpassen...
(Der pulse-water-meter hat auch schon einen millis()-Pfad. Der sollte sich einfach mit dem "Taster"-bounce2()-Code (in Array-Form) "verheiraten" lassen (so nutze ich das jedenfalls bei anderen meiner Sketche).)

Für FHEM-Zwecke kann man das vermutlich vereinfachen, schlicht alle paar Minuten einen Differenzwert senden und die Statistik in FHEM erstellen (userreading monotonic, oder statistics).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

flipse

Zitat von: Beta-User am 08 Juli 2019, 09:33:56
Gut, dass sich das mit der Verkabelung geklärt hat.

Aber wieso willst du für den Wasserzähler extra Hardware nehmen?

Geht zwar vielleicht auch, aber dafür war die Empfehlung, D2/D3 freizuhalten. Diese beiden PINs sind nämlich dahingehend anders, dass die (für den jeweilien PIN direkt eine Aussage treffende) Interrupts liefern, was z.B. für Zählerzwecke recht einfach genutzt werden kann. Basis wäre da dieser Sketch: https://www.mysensors.org/build/pulse_water. Wenn du einen weiteren Zähler haben wolltest: einfach die ISR (Interrupt Service Routine, bei diesem Sketch: "onPulse") doppeln und entsprechend anpassen...
(Der pulse-water-meter hat auch schon einen millis()-Pfad. Der sollte sich einfach mit dem "Taster"-bounce2()-Code (in Array-Form) "verheiraten" lassen (so nutze ich das jedenfalls bei anderen meiner Sketche).)

Für FHEM-Zwecke kann man das vermutlich vereinfachen, schlicht alle paar Minuten einen Differenzwert senden und die Statistik in FHEM erstellen (userreading monotonic, oder statistics).

Klar, kann ich auch den TCRT5000 nehmen. Ich dachte es wäre einfacher, den DS2423 zu nutzen und an den Arduino anzuschließen.
Hat jemand schon mal ein Gehäuse für den TCRT5000 i.V.m. Sensus Zählern?

Beta-User

Weiß nicht, ob du den TCRT da brauchst.

Wenn du im Prinzip einen Impuls für S0-Zähler hast, kannst du den Impulsgeber direkt anschließen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

flipse

Zitat von: Beta-User am 08 Juli 2019, 13:25:09
Weiß nicht, ob du den TCRT da brauchst.

Wenn du im Prinzip einen Impuls für S0-Zähler hast, kannst du den Impulsgeber direkt anschließen...

Ich habe an dem Zähler keinen Anschluss gesehen

Beta-User

Wie soll dann der DS2423 weiterhelfen? Um zu funktionieren, braucht der auch irgendwoher einen Puls. Daher hatte ich unterstellt, dass ein solcher schon vorhanden ist ??? .
Wenn nicht, solltest du überlegen, den Zähler gegen einen auszutauschen, der einen S0-Anschluß hat. Wasserzähler sind "speziell", vermutlich funktioniert da die Infrarot-Abtastung nicht, wenn dann nur analog mit selbstregelnder Kalibierung und und und... Es sei denn, es würde magnetisch mit einem Reed-Kontakt gehen. Wenn du dein Modell hast, kannst du ja in dem "Wasserzähler-Thread" mal suchen, was es ggf. dafür an Ideen gibt oder konkret nachfragen, wenn "die Suchmaschine deiner Wahl" keinen Treffer liefert.

Das solltest du zuerst recherchieren, und bis dahin einfach PIN2/3 freihalten bzw. den Code gleich so schreiben, dass der Arduino da jeweils ohne weitere 1-wire Hardware korrekt zählen würde ;D . Testen kannst du die Funktionalität ja schon mal vorab, da reicht ein simpler Taster.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

flipse

Zitat von: Beta-User am 08 Juli 2019, 14:13:46
Wie soll dann der DS2423 weiterhelfen? Um zu funktionieren, braucht der auch irgendwoher einen Puls. Daher hatte ich unterstellt, dass ein solcher schon vorhanden ist ??? .
Wenn nicht, solltest du überlegen, den Zähler gegen einen auszutauschen, der einen S0-Anschluß hat. Wasserzähler sind "speziell", vermutlich funktioniert da die Infrarot-Abtastung nicht, wenn dann nur analog mit selbstregelnder Kalibierung und und und... Es sei denn, es würde magnetisch mit einem Reed-Kontakt gehen. Wenn du dein Modell hast, kannst du ja in dem "Wasserzähler-Thread" mal suchen, was es ggf. dafür an Ideen gibt oder konkret nachfragen, wenn "die Suchmaschine deiner Wahl" keinen Treffer liefert.

Das solltest du zuerst recherchieren, und bis dahin einfach PIN2/3 freihalten bzw. den Code gleich so schreiben, dass der Arduino da jeweils ohne weitere 1-wire Hardware korrekt zählen würde ;D . Testen kannst du die Funktionalität ja schon mal vorab, da reicht ein simpler Taster.

da bin ich gerade dran ;)
ich war der Meinung der DS2324 ist die gesamte Einheit inkl. optischer Abtastung. Dann habe ich mich vertan ;)
Nein. Ich habe keine S0 Schnittstelle, die ich abgreifen kann.

flipse

So, jetzt ist der Code soweit aufgeräumt und so angepasst, dass ich über Variablenänderung die Pins mit deren Funktion bestimmen kann.
Der Sensor zur Abtretung des Wasserzählers ist auch vorbereitet. Sobald ich morgen die Hardware habe, werde ich es testen.

Wie kann ich nun erreichen, dass FHEM nicht 1 Device, sondern mehrere aus dem jeweiligen Kontaktsensor erstellt?
Dankeschön

Beta-User

Zitat von: flipse am 08 Juli 2019, 22:23:49
Wie kann ich nun erreichen, dass FHEM nicht 1 Device, sondern mehrere aus dem jeweiligen Kontaktsensor erstellt?
Mit den Stichworten von hier hast du schon gespielt?
Zitat von: Beta-User am 07 Juli 2019, 09:41:23
- Es sollte möglich sein, die Infos zu vereinzeln.
-- Was in jedem Fall geht, wäre ReadingsProxy.
-- Was vielleicht geht, wäre die ID zu klonen und jeweils ein (oder mehrere) Reading(s) auf einer eigenen MYSENSORS_DEVICE-Instanz zu haben (habe ich selbst praktisch keine Erfahrung mit, soll aber gehen...)
Vorab wäre aber die Frage, ob du überhaupt Einzeldevices benötigst, und wenn ja, zu welchem Zweck.
Im Rahmen reiner Automatisierungsaufgaben ist es völlig irrelevant, ob die jeweilige Info in einem eigenen Device steht oder in einem Reading eines mehrkanaligen "Großdevices". Vereinzeln macht nur dann Sinn, wenn du das zu Anzeigezwecken brauchst (z.B. pro Raum ein oder zwei Readings anzeigen? => dann eher ReadingsProxy oder evtl. readingsGroup), oder ob z.B. ein Modul Events an einem separaten Device benötigt (AutoShuttersControl könnte so ein Fall sein, wobei da evtl. noch dazu kommt, dass auch ReadingsProxy vielleicht nicht in jedem Fall die erwarteten state-Events liefert (bitte ggf. verifizieren!); dafür stehen die Infos da schon im state, was die grafische Anzeige einfacher macht...).

Was den 2. Weg (Device einfach klonen) angeht: ich habe das nur kurz angetestet und weiß, dass das grundsätzlich funktioniert; ich kann aber nicht sagen, bei welchem Device dann z.B. neue Readings angelegt werden, usw.. Da solltest du ggf. einfach mal testen, ob sich das so verhält, wie du das brauchst, oder ob nicht ein anderer Weg besser ist. Dazu würde ich aber empfehlen, ggf. einen eigenen Thread im MySensors-Bereich aufzumachen, da gibt's nämlich Leute, die damit mehr Erfahrung haben...

Ansonsten gilt, wie immer bei FHEM: viele Wege führen nach Rom...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

flipse

#42
Zitat von: Beta-User am 09 Juli 2019, 07:18:15
Mit den Stichworten von hier hast du schon gespielt?Vorab wäre aber die Frage, ob du überhaupt Einzeldevices benötigst, und wenn ja, zu welchem Zweck.
Im Rahmen reiner Automatisierungsaufgaben ist es völlig irrelevant, ob die jeweilige Info in einem eigenen Device steht oder in einem Reading eines mehrkanaligen "Großdevices". Vereinzeln macht nur dann Sinn, wenn du das zu Anzeigezwecken brauchst (z.B. pro Raum ein oder zwei Readings anzeigen? => dann eher ReadingsProxy oder evtl. readingsGroup), oder ob z.B. ein Modul Events an einem separaten Device benötigt (AutoShuttersControl könnte so ein Fall sein, wobei da evtl. noch dazu kommt, dass auch ReadingsProxy vielleicht nicht in jedem Fall die erwarteten state-Events liefert (bitte ggf. verifizieren!); dafür stehen die Infos da schon im state, was die grafische Anzeige einfacher macht...).

Was den 2. Weg (Device einfach klonen) angeht: ich habe das nur kurz angetestet und weiß, dass das grundsätzlich funktioniert; ich kann aber nicht sagen, bei welchem Device dann z.B. neue Readings angelegt werden, usw.. Da solltest du ggf. einfach mal testen, ob sich das so verhält, wie du das brauchst, oder ob nicht ein anderer Weg besser ist. Dazu würde ich aber empfehlen, ggf. einen eigenen Thread im MySensors-Bereich aufzumachen, da gibt's nämlich Leute, die damit mehr Erfahrung haben...

Ansonsten gilt, wie immer bei FHEM: viele Wege führen nach Rom...


Die Begründung ist, dass ich das Device gerne in Homekit einbinden möchte.
Ja, ich weiß, dass man mit einem entsprechenden HomebridgeMapping aus 1 Device auch mehrere Homekit Devices generieren kann.
Aber ich finde die Übersichtlichkeit in FHEM jetzt einfach ganz gut. So habe ich für jeden Türkontakt ein Device, was auch ein rotes Icon mit offener Türe zeigt, wenn der Kontakt offen ist etc.

Ich schaue mir das readingsProxy mal an

flipse

Zitat von: Beta-User am 10 Juli 2019, 10:02:40
Hmm,

irgendwie finde ich die Frage hier in diesem Thread in der Nähe von OT (der TE war ja jemand anderes!). Bitte daher ggf. entweder direkt bei MySensors.org einen Thread aufmachen, oder wenigstens hier im MySensors-Bereich (alternativ, da sich die Frage vermutlich im wesentlichen an mich richtet: in deinem eigenen "direkt-anbinden-Thread). Das folgende bleibt daher das einzige, was ich konkret darauf aufworte:

Such mal nach Arduino und micros() (darauf beziehen sich alle Variablen in der ISR):Damit ist diese ominöse hohe Zahl eine Minute, oder...?

Was den PULSE_FACTOR angeht, steht im Original:
#define PULSE_FACTOR 1000                       // Number of blinks per m3 of your meter (One rotation/liter)Was da ursprünglich stand, bedeutete also: "ein Blink ist ein Liter". Du hast jetzt "ein Blink ist ein m³" draus gemacht, was tatsächlich vom Sketch als "too much" verworfen wird...

ok, das habe ich angepasst und wieder rückgängig gemacht.
wo kann ich denn definieren, ab wann ich in FHEM eine Rückmeldung bekomme.
möchte das am Anfang recht häufig haben zum testen.
derzeit tauchen nicht mal die readings auf.

Beta-User

Die Zeit wird im Sketch durch "SEND_FREQUENCY" bestimmt, per default also 30 Sekunden.

Allerdings kann es sein, dass ohne Pulse auch "nichts" gesendet wird, was dann dazu führt, dass die Readings nicht gefüllt werden. Du solltest also den Sensor schon irgendwas zählen lassen, damit auch was anderes als "empty" payload generiert wird.

Und: Neue Readings sieht man uU. erst, wenn man die betr. Seite neu lädt (F5@firefox).

Weiter sind in dem "Water-Pulse-Sensor" Sketch auch einige serielle Ausgaben drin, die evtl. nicht optimal sind; kommentiere die mal aus. Die kommen sonst nämlich - anders als bei einer "normalen" node - beim GW genau so auch an und müssen von diesem geprüft (und verworfen) werden. Kann sein, dass dadurch was durcheinanderkommt (sollte eigentlich nicht, aber das ist auch für mich Neuland).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors