Plugin: 1-Wire-NG

[74homer]

Ich konnte das Problem mit dem Reed-Kontakt lösen.
Die Ursache war mechanisch, d.h. der Abstand zwischen dem Magnet-Detektor und dem Magnet war zu groß (10mm).
Erst nachdem ich den Abstand auf 5mm verringert habe funktioniert der Reed-Kontakt wie erwünscht.

[74homer]

Hallo,

welche GPIO Pins des Raspi werden mit dem I2C Busmasters (siehe auch hier) für 1-Wire verwendet?
(Pin 2/4 sind 5V PWR (Spannungsversorgung), Pin 6/9/14/20/25/30/34/39 sind GND.)

[wAllAcEr]

Hallo und guten Abend,

ich möchte mich hiermit mal mit einem Problem an euch melden und hoffe, dass ihr mir bei der Fehlersuche / Lösung behilflich sein könnt.
Folgendes Setup:
Rapsi 4B Nr.1: IOBroker mit MQTTBroker. läuft zuverlässig, stabil, keine Probleme.
Raspi 4B Nr.2: Loxberry, frisch aufgesetzt, 1-Wire-NG installiert, ein DS9490R dran, ein DS2438 dran, eingestellt und sendet per MQTT an Raspi Nr.1 (auch das funktioniert soweit).

Nun mein Problem:

in der MQTT Message werden die Daten von DS2438 gesendet. Allerdings interessieren mich so Sachen wie timestamp, address, uncached, vad, vdd nicht. Ich möchte eigentlich nur VIS, Temperature und Present im IOBroker erhalten. Gesendet werden aber z.B. folgende Messages:


{"vis":"0.0002441","Uncached":"0","address":"26 FC7 B35020000","timestamp":"1610305183.79506","bus":"b us.0"}
{"temperature":"22.5","timestamp":"1610305143.5 426 ","bus":"bus.0","address":"26FC7B35020000","Un cach ed":"0"}
{"vis":"0","timestamp":"1610305143.5426","bus": "bus.0","address":"26FC7B35020000","Uncached": "0"}
{"temperature":"22.4688","bus":"bus.0","timesta mp" :"1610305103.35778","address":"26FC7B35020000", "Un ached":"0"}
{"temperature":"22.5","timestamp":"1610305083.2 516 1","bus":"bus.0","address":"26FC7B35020000","Un cac hed":"0"}
{"vis":"0.0002441","address":"26FC7B35020000"," Unc ached":"0","timestamp":"1610305083.25161","bus":"b us.0"}
{"vis":"0.0002441","address":"26FC7B35020000"," Unc ached":"0","timestamp":"1610305083.25161","bus":"b us.0"}


Diese Reihenfolge kam in chronologischer Reihenfolge, eingestellt auf 10 Sekunden. Wie man sieht, fehlt hin und wieder vis oder temp, mal fehlt nur ein Wert, mal beide. Present fehlt allerdings sehr häufig. Für die Auswertung im IOBroker ist das für mich aber ein Problem.

Gibt es irgendeine Möglichkeit, die Werte, welche gesendet werden, zu kürzen, oder abzuwählen/auszuschließen? Habe in der owfs2mqtt.pl in zeile 395 was gefunden, aber selbst wenn ich dort schreibe:
$values = "vis,temperature";
gibt das keine Änderung.
Auch im OWFS-Server kann ich keine Möglichkeit finden, etwas in der Richtung einzustellen.

In den Einstellungen zum Senseor im 1-Wire-NG Plugin habe ich unter values natürlich vis und temperature eingetragen und Check Präsenz aktiviert.

Wäre schön, wenn mir jemand bei diesem Problem helfen könnte!

Danke und viele Grüße

[SehlingS]

Hey zusammen,

mein Logordner vom 1Wire Plugin ist wieder auf root als onwer gegangen.
Dadurch kann eure Routine die Logfiles nicht löschen.
Das hatte ich vor einem Monat schon mal.

Jemand ne idee woran das liegen könnte?
Ich ändere jetzt den owner wieder manuell auf loxberry, dann sollte es wieder gehen.

Grüße
Sascha

[Christian Fenzl]

Hast du irgendwelche zeitlichen Indizien? Normal zur Laufzeit, nach einem Reboot oder dergleichen?

[Christian Fenzl]

Vermutlich läuft das Plugin als root.
Prof.Mobilux?

[Prof.Mobilux]

owfs weiß ich grad nicht. owfs2mqtt.pl (das ist das Skript vom Plugin) läuft als loxberry. https://github.com/mschlenstedt/LoxB...tchdog.pl#L131

[SehlingS]

Schwer zu sagen, mir ist es erst aufgefallen, also der Health check "gemeckert" hat

Ich schaue mir jetzt öfter mal den Ordner an und beobachtet das Ganze. Aber wenn ihr das ja über das Skript löst ist es ja egal wer Owner ist.

[wAllAcEr]

Hat niemand eine Idee, wie man das Problem mit den MQTT-Messages beheben kann?

[Christian Fenzl]

Das ist doch ein Thema von ioBroker.
Ich weiß nicht, wie du dort die json-Payload verarbeitest, aber im MQTT Gateway beispielsweise ist es mir herzlich egal, in welcher Reihenfolge die Daten im json stehen.

[wAllAcEr]

Das ist doch ein Thema von ioBroker.
Ich weiß nicht, wie du dort die json-Payload verarbeitest, aber im MQTT Gateway beispielsweise ist es mir herzlich egal, in welcher Reihenfolge die Daten im json stehen.

Danke für deine Antwort.

Ich glaube jedoch nicht, dass das ein Problem vom ioBroker ist. Wenn ich in Windows mit dem Programm MQTTBox das Topic subscribe, dann erhalte ich die Ausgaben, die ich oben eingefügt habe. Sprich die Messages aus meinem Post stammen aus "MQTTBox". Daher geht meine Vermutung dahin, dass es nicht korrekt aus dem 1-Wire-NG-Plugin raus geschickt wird.
BTW: andere MQTT-Topics mit bedeutend mehr Zeichen werden problemlos im ioBroker-MQTT-Broker erfasst (so z.B. Tasmota Messages).

Die Json verarbeite ich mit einem Blockly/Javascript. Als Beispiel hier mal das Blockly:

<xml xmlns="https://developers.google.com/blockly/xml">
<block type="schedule" id=")}iY`)VqgW];2oYT[!L4" x="-262" y="113">
<field name="SCHEDULE">*/10 * * * * *</field>
<statement name="STATEMENT">
<block type="procedures_callcustomnoreturn" id=".SUNAb;yu94^zP/{E~8}">
<mutation name="calc3dprintercost"></mutation>
</block>
</statement>
</block>
<block type="procedures_defcustomnoreturn" id="enK7^[CkGvQ3`.H}Bsv!" x="-362" y="238">
<mutation statements="false"></mutation>
<field name="NAME">calc3dprintercost</field>
<field name="SCRIPT">ICBqc29uID0gKGZ1bmN0aW9uICgpIHsgdHJ5 IHtyZXR1cm4gSlNPTi5wYXJzZShnZXRTdGF0ZSgibXF0dC4wLm 93ZnMuc3RhdHVzLjI2LkZDN0IzNTAyMDAwMCIpLnZhbCk7fSBj YXRjaChlKSB7cmV0dXJuIHt9O319KSgpOw0KICBzZXRTdGF0ZS gibXF0dC4wLm93ZnMuc3RhdHVzLjI2LlRlbXAiLCBNYXRoLnJv dW5kKChnZXRBdHRyKGpzb24sICd0ZW1wZXJhdHVyZScpICogZ2 V0U3RhdGUoImphdmFzY3JpcHQuMC52YXJpYWJsZXMuRWlucyIp LnZhbCkqMTAwKS8xMDAsIHRydWUpOw0KICBzZXRTdGF0ZSgibX F0dC4wLm93ZnMuc3RhdHVzLjI2LlZJUyIsIE1hdGgucm91bmQo KGdldEF0dHIoanNvbiwgJ3ZpcycpICogZ2V0U3RhdGUoImphdm FzY3JpcHQuMC52YXJpYWJsZXMuRWlucyIpLnZhbCkqMTAwKSwg dHJ1ZSk7</field>
<comment pinned="false" h="80" w="160">Beschreibe diese Funktion …</comment>
</block>
</xml>

In dem Javascript steht dann folgendes:

json = (function () { try {return JSON.parse(getState("mqtt.0.owfs.status.26.FC7B350 20000").val);} catch(e) {return {};}})();
setState("mqtt.0.owfs.status.26.Temp", Math.round((getAttr(json, 'temperature') * getState("javascript.0.variables.Eins").val)*100)/100, true);
setState("mqtt.0.owfs.status.26.VIS", Math.round((getAttr(json, 'vis') * getState("javascript.0.variables.Eins").val)*100), true);

Dabei ist dem Script auch vollkommen egal, in welcher Reihenfolge die Daten kommen, wichtig ist nur, dass die genannten Daten: vis, temp und presence IMMER übermittelt werden. (und Sachen wie bus, timestamp, uncached, address können gerne entfallen)
Und dieses Problem möchte ich gerne beheben.

Danke schonmal

PS: eins ist mir noch aufgefallen:
im MQTT-Gateway auf dem Loxberry, werden immer alle Daten des Sensors zur gleichen Zeit erfasst (Also vis, temp, presence, address, bus, uncached, timestamp). Dort "fehlt" quasi nie ein Status. (das MQTT-Gateway läuft natürlich als Client, Broker ist der ioBroker).

[Prof.Mobilux]

Die Werte fehlen vermutlich, weil sie sich nicht geändert haben. Das müsste ich mir mal anschauen. Ich glaube mich zu erinnern, dass ich cache und dann nur das schicke, was sich ändert.

[wAllAcEr]

Die Werte fehlen vermutlich, weil sie sich nicht geändert haben. Das müsste ich mir mal anschauen. Ich glaube mich zu erinnern, dass ich cache und dann nur das schicke, was sich ändert.

Perfekter Lösungsansatz!!

Habe das gerade versucht nachzustellen und es ist exakt so! Doof, dass ich da nicht eher drauf gekommen bin

Jetzt stellt sich nur die Frage, wie man das beheben kann Eventuell gibt es auch eine Möglichkeit, das für jeden Sensor individuell einzustellen (Wert bei Nicht-Änderung senden: ja/nein)?!

Vielen Dank im Voraus

[Christian Fenzl]

Prof.Mobilux Im Grunde könntest du auf deinen Cache verzichten, weil das Gateway selbst auch cached.

[Prof.Mobilux]

Mmhh, ach so, stimmt. Ich wollte halt nicht so viel zum Gateway senden wenn nicht notwendig. Ich könnte sicherlich meinen Cache auch deaktivierbar machen - wenn ich denn nur ein wenig Zeit hätte ;-)

[74homer]

Hallo,
ich habe die Version 1.0.1 des Plugins erfolgreich in Betrieb genommen.
Alle angeschlossenen 1-Wire Geräte (Tp-Sensoren, Fensterkontakte) werden erkannt.
In der Übersicht werden folgende Prozesse (mit PID) angezeigt:
- OWServer
- OWHTTPD
- OWFS2MQTT


Nach ca. 12h Betrieb erhalte ich von Loxone Fehlermeldungen, die alle 1-Wire Geräte betreffen. Das heißt, alle Sensoren liefern keine Werte mehr.

Ich vermutete einen Zusammenhang mit der Strom-Versorgung des Rpi, aber der Selbsttest von Loxberry zeigt keinen Fehler:


Dann habe ich mir die Übersicht des Addons nochmals genau angesehen; es ist klar ersichtlich, dass die 3 Prozesse aktiv sind (grün), aber die Anzahl der PIDs hat sich massiv geändert.
Der Prozess OWFS2MQTT lief zuvor mit 8 PIDs, jetzt sind es nur noch 1 oder 2!

Die Fehleranalyse ist gegenwärtig nicht möglich, weil vermeintlich ein Watchdog im Falle eines Fehlers die zum Addon gehörenden Services automatisch neu startet.

Deshalb ist meine Frage:
Wie kann der Watchdog für das Addon 1-Wire NG deaktiviert werden?

Oder wie kann man anders ermitteln, warum die Prozesse sterben?

THX

[TomekWaw]

My 1-wire-NG plugin seems to log much:

root@loxberry:/opt/loxberry/log/ramlog/log/plugins# du -sh * |sort -rh| head -n10
49M 1-wire-ng
868K mqttgateway

I've already set logging to level to "off", but it doesn't help much.
Seems that plugin creates a large number of files with single line in it:

root@loxberry:/opt/loxberry/log/ramlog/log/plugins/1-wire-ng# du -sh * |sort -rh |head -n5
4.0K 20210330_174901_722_watchdog.log
4.0K 20210330_174801_645_watchdog.log
4.0K 20210330_174701_591_watchdog.log
4.0K 20210330_174601_563_watchdog.log
4.0K 20210330_174502_259_watchdog.log

root@loxberry:/opt/loxberry/log/ramlog/log/plugins/1-wire-ng# ls -al |wc -l
11820

It's almost 13 thousand log files crated since last reboot (~40 days).
Can I do something about it?
I don't really need any 1-wire logging

[74homer]

Warum werden mehrere Prozesse des Programm /opt/loxberry/bin/plugins/1-wire-ng/owfs2mqtt.pl benötigt, damit dieses Plugin funktioniert?

loxberry 3074 1 2 17:45 ? 00:00:00 /usr/bin/perl /opt/loxberry/bin/plugins/1-wire-ng/owfs2mqtt.pl bus=7 verbose=0
loxberry 3085 1 2 17:45 ? 00:00:00 /usr/bin/perl /opt/loxberry/bin/plugins/1-wire-ng/owfs2mqtt.pl bus=6 verbose=0
loxberry 3096 1 3 17:45 ? 00:00:00 /usr/bin/perl /opt/loxberry/bin/plugins/1-wire-ng/owfs2mqtt.pl bus=5 verbose=0
loxberry 3107 1 3 17:45 ? 00:00:00 /usr/bin/perl /opt/loxberry/bin/plugins/1-wire-ng/owfs2mqtt.pl bus=4 verbose=0
loxberry 3118 1 3 17:45 ? 00:00:00 /usr/bin/perl /opt/loxberry/bin/plugins/1-wire-ng/owfs2mqtt.pl bus=3 verbose=0
loxberry 3133 1 3 17:45 ? 00:00:00 /usr/bin/perl /opt/loxberry/bin/plugins/1-wire-ng/owfs2mqtt.pl bus=2 verbose=0
loxberry 3146 1 2 17:45 ? 00:00:00 /usr/bin/perl /opt/loxberry/bin/plugins/1-wire-ng/owfs2mqtt.pl bus=1 verbose=0
loxberry 3159 1 2 17:45 ? 00:00:00 /usr/bin/perl /opt/loxberry/bin/plugins/1-wire-ng/owfs2mqtt.pl bus=0 verbose=0

[Christian Fenzl]

Was ist das überhaupt für eine Ausgabe?

[Prof.Mobilux]

Für jeden Bus eine Instanz.

[74homer]

Das ist die Ausgabe von

ps -ef | grep owfs2mqtt

.

Ich habe inzwischen herausgefunden, wo der watchdog steckt und wie er deaktiviert werden kann.
Dadurch ist es mir möglich, alle zum 1-Wire-Plugin gehörenden Services und Programme manuell zu starten.
Der Start von

/opt/loxberry/bin/plugins/1-wire-ng/owfs2mqtt.pl

hat dann gezeigt, warum das Programm fehlschlägt: Die SQLite DB war korrupiert.

Nachdem ich die DB repariert habe, funktioniert das 1-Wire-Plugin und die damit verbundenen Services und Programme.

Es ist verständlich, dass für jeden Bus eine Instanz des Programms

/opt/loxberry/bin/plugins/1-wire-ng/owfs2mqtt.pl

laufen muss.
Aber warum werden 8 Instanzen gestartet, und nicht 2 oder 4 oder 16?
Oder ist die Anzahl der 1-Wire Bus hard codiert auf 8?

In der Annahme, dass 1-Wire Bus genau 1 Kabel entspricht, das an das 1-Wire Modul angeschlossen ist, wäre es dann nicht sinnvoll, die Anzahl der Busse über die WebUI festzulegen?

[Prof.Mobilux]

Aber warum werden 8 Instanzen gestartet, und nicht 2 oder 4 oder 16?
Oder ist die Anzahl der 1-Wire Bus hard codiert auf 8? In der Annahme, dass 1-Wire Bus genau 1 Kabel entspricht, das an das 1-Wire Modul angeschlossen ist, wäre es dann nicht sinnvoll, die Anzahl der Busse über die WebUI festzulegen?

ich weiß jetzt nicht was das mit einem Kabel zu tun hat, aber egal. Auf jeden Fall werden bei Dir 8 Instanzen gestartet, weil owfs bei Dir 8 einzelne Busse gefunden hat. Findet er 7, startet er 7 Instanzen. Findet er 9, startet er 9 Instanzen.

Keine Ahnung was Du da bei Dir wie konfiguriert hast. Auf jeden Fall existieren bei Dir 8 Busse. Deswegen eben auch 8 Instanzen.