1Wire am EibPC

[rennsemmel]

Bin ich vieleicht schon am vorläufigen Ziel und Dein Makro kann bereits ein quasi paralleles Auslesen der Sensoren dank nicht parasitärem Betrieb?

Nein, das Makro ist nicht so schlau um festzustellen, ob es mit parasitärer oder aktiver Versorgung läuft. Momentan läuft das so, das bei einem Read-Request die Warteschlange im die notwendigen Abfragebefehle ergänzt wird. Sollte der Sensor schon in der Schlange drinstehen, dann passiert halt nix.

Was ich meinte war, dass alle 12 Sensoren nach ca 30-40 sec auf meinem Schirm erscheinen. Nicht also der letzte erst nach 12x20sec=240sec=4min. Es wird bei mir scheinbar deutlich weniger als die bekannten ~20 sec benötigt um eine Abfrage zu bearbeiten. (Was noch zu beweisen ist - Fortsetzung folgt.)

[kirekey]

Hallo rennsemmel,

wir haben evtl. recht ähnliche Anforderungen an die 1-wire Nutzung mittels EibPC. Ich habe mich schon ein paar Tage mit dem Thema beschäftigt und bin mit meinem Testaufbau in der Lage, innerhalb von ca. 3 Sekunden die aktuellen Temperaturwerte von 50 Sensoren im Browser anzuzeigen, wobei das nur deshalb so "lange" dauert, weil bei meinem simplen Testscript der Browser 51 AJAX-Requests sendet (1x "Broadcast" an alle Sensoren + 50x Temperaturwert auslesen).

Ich nutze dafür den IP-Extender von Wiregate, also einen normalen TP-Link Router. Eine Grenze bzgl. Anzahl der Sensoren gibt es bei dieser Lösung quasi nicht. Die beiden Makros für den EibPC sind in der von dir genannten Enertex-Lib bereits enthalten. Weitere Informationen zu meinen Vorüberlegungen findest du u.a. hier und hier. Bei beiden Themen ging es um die Suche nach Fehlern, die in der Vergangenheit bei dieser Lösung aufgetreten waren, die nun aber gefunden und behoben sind.

Grüße
Erik

[rennsemmel]

Hallo Erik,

danke der Hinweis passt und es ist gut zu wissen das es geht, obwohl ich die Wiregate Extender Lösung wohl erstmal vieleicht später weiter im Detail verfolgen werde da es wieder ein neues Gerät in der Kette ist.
Ein weiterer Punkt der mich abschrekte war: Enertex stellt die .lib zum extender auf obsolete, was für mich bedeutet keine garantie dass er in den nächsten releases noch unterstützt wird.

Denoch bin ich neugierig:
Bei 50 Sensoren nehme ich an, dass Du einen nicht parasitären (mit 5V) Betrieb hast.
Den Wiregate Extender scheint es so nicht mehr zu geben bzw muss man sich selber zusammmen bauen richtig?

[bmx]

Moin Erik,

... innerhalb von ca. 3 Sekunden die aktuellen Temperaturwerte von 50 Sensoren im Browser anzuzeigen, wobei das nur deshalb so "lange" dauert, weil bei meinem simplen Testscript der Browser 51 AJAX-Requests sendet (1x "Broadcast" an alle Sensoren + 50x Temperaturwert auslesen).

Bist Du sicher, das die Sensoren ausgelesen werden? Ich könnte mir auch vorstellen, das Du die aus dem owfs Cache vom IP Extender liest.

Gruß,
Bernd

[kirekey]

... obwohl ich die Wiregate Extender Lösung wohl erstmal vieleicht später weiter im Detail verfolgen werde da es wieder ein neues Gerät in der Kette ist.

Kein weiteres, sondern ein anderes Gerät, der HA7E wird nicht mehr benötigt.

Ein weiterer Punkt der mich abschrekte war: Enertex stellt die .lib zum extender auf obsolete, was für mich bedeutet keine garantie dass er in den nächsten releases noch unterstützt wird.

Das "obsolet" bezieht sich eher auf die Weiterentwicklung der Bibliothek, was ohne neue Hardware auch nicht viel Sinn macht. Die Kommunikation mit dem IPE geschieht über TCP-Funktionen und diese sind Bestandteil der Option NP, welche auch in Zukunft nicht aus dem EibPC verschwinden wird. Und wenn du dir mal die entsprechenden Makros genauer ansiehst und den ganzen Debug-Code gedanklich entfernst, wirst du feststellen, dass die Implementierung kein Hexenwerk ist...

Bei 50 Sensoren nehme ich an, dass Du einen nicht parasitären (mit 5V) Betrieb hast.

Richtig, aber das hat nichts mit der Anzahl der Sensoren zu tun, sondern ist Bedingung für die simultaneous Funktionalität.

Den Wiregate Extender scheint es so nicht mehr zu geben bzw muss man sich selber zusammmen bauen richtig?

Ja, leider. Stefan und Makki haben schon mehrfach zum Ausdruck gebracht, dass das einfache Kopieren des Gerätes eine Weiterentwicklung nicht mehr rentabel macht, was sie wohl nun zur kompletten Aufgabe des IPE veranlasst hat. Die Frage ist, wie sie nun zum Thema "Kopie" stehen. Um ein defektes Gerät austauschen zu können, ist man ja jetzt darauf angewiesen...

Bist Du sicher, das die Sensoren ausgelesen werden? Ich könnte mir auch vorstellen, das Du die aus dem owfs Cache vom IP Extender liest.

Nach meinen Recherchen und Tests verhält es sich so, dass ein simultaneous Befehl den owfs Cache löscht und bei allen Temperatursensoren eine gleichzeitige Konvertierung auslöst. Bei einem anschließenden Lesebefehl innerhalb von 10s wird keine erneute Konvertierung durchgeführt, sondern der zuvor berechnete Temperaturwert durch den jweiligen Sensor zurückgegeben. Der owfs Cache (per default ebenfalls 10s gültig) würde bei allen weiteren Lesebefehlen innerhalb von 10 Sekunden verwendet werden, sofern nicht zuvor ein erneuter simultaneous Befehl erfolgt, welcher den Cache wieder leeren würde.

Grüße
Erik

[kirekey]

Der Vollständigkeit halber sollte ich vielleicht noch erwähnen, dass der nicht-parasitäre Betrieb bei Verwendung des IPE nicht grundsätzlich notwendig ist. In diesem Fall werden die Konvertierungen nacheinader ausgeführt, was mit den aktuellen Makro-Einstellungen bei voller Auflösung jeweils etwas mehr 1s braucht, also eine gute Minute bei 50 Sensoren.

Wichtig ist dann allerdings, die Startzeit der einzelnen Abfragen genau zu timen, damit eine Abfrage nicht auf vorhergehende Abfragen warten muss und es zu einem Timeout der TCP-Verbindung kommt. Alternativ kann der Timeout-Wert im Makro erhöht werden, wobei ich nicht weiß, ob es beim EibPC eine Grenze bzgl. gleichzeitiger Verbindungen gibt bzw. wie hoch diese ist.

Grüße
Erik

[rennsemmel]

Sensorwerte frieren ein

Hallo,

eigentlich wollte ich ja noch den Beweis erbringen, dass die bmxha7e_15a.lib im nicht parasitären Betrieb 12 Sensoren im Zeitabstand von 5 sec auslesen kann.

UND NUN DAS: Ich habe einen Raspberry pi mit netcat zum Loggen mitlaufen. Seit meinem letzten Beitrag (04.03.2014) hatte ich den eibPC nicht mehr angefasst und die Temperaturerfassung lief prima. Dabei werden ein Sensor alle 5 sec, ein Sensor alle 20 sec und die restlichen mit 120 sec ausgelesen. Zur Erinnerung: Es sind 12 Stück DS18B20 im nicht parasitären Betrieb am Ha7e im Einsatz.
Nachdem ich NUR den Code im eibPC um das Loggen mit sendudp erweitert habe (ich habe den Code für die Temperaturerfasung nicht angefasst), läuft die Abfrage der 1-Wire Sensoren nicht mehr reibungsfrei. Nach den ersten Starts blieben einige Sensoren auf 85°C (init wert) stehen. Dann schien alles zu laufen. Jedoch sind die Sensorwerte nach ca 1,5 Tagen nacheinander nicht mehr geupdatet worden, was zur Folge hatte das es sehr Warm wurde.

Eigentlich wollte ich mich weiter damit beschäftigen, über 20 Sensoren zu betreiben.
Nun muss ich aber nochmal an den Anfang zurück und Fragen:
Woran liegt es dass die Werte einfrieren? Gibt es Abstellmöglichkeiten?
Sind doch die 5 bzw 20 sec schuld?
Macht es Sinn einen Reset des Systems zu erwirken, wenn z.B. innerhalb der letzten 2 Stunden sich die Sensorwerte nicht mehr verändert haben. Hat jemand so etwas bereits geschrieben und kann mir einen Beispiel code zur
Verfügung stellen?

Daneben würde ich gerne von 3.000 auf die Version 3.009 up daten.
Mir ist jedoch zu Ohren gekommmen, das nach einem update auf die 3.009 ggf. die 15a.lib nicht mehr läuft. Sind hier weitere Erfahrungen mit der 15a.lib und der 3.009 gemacht worden und Lösungen vorhanden?
Gibt es eine Möglichkeit wieder auf eine ältere als 3.009 Version zurück zu gehen, falls die 15a.lib nicht mehr läuft?

[bmx]

Moin,

die bmxha7e_15a.lib kann ich in Verbindung mit EibPC V3 derzeit nicht empfehlen. Ich habe zwar eine angepasste Version erstellt aber die funktioniert derzeit nicht zuverlässig. Ich habe aus Zeitmangel auch keine Möglichkeit daran weiterzuarbeiten.

Wer den HA7E nutzt und drauf angewiesen ist sollte IMHO beim derzeitigen Stand der Firmware lieber auf der 2.x bleiben.

Gruß,
Bernd

PS: die 15e läuft und hat folgendes drin:

[highlight=epc]
:begin HA7E_DebugOut_String( argDebugLevel, OutMessage )
:info $Send a text string to a UDP receiver$
:shortinfo $Send debug messages via UDP$
#ifndef HA7E_NO_DEBUG
:var tmpOutMsg@
tmpOutMsg@ = $$
:return if (HA7E_DebugLevel and argDebugLevel) > 0u08 then {
tmpOutMsg@ = Debug_Currenttime+$ HA7E:$+ OutMessage+ $<br>$;
HA7E_DebugInfo = tmpOutMsg@ + HA7E_DebugInfo ;
} endif;
#endif HA7E_NO_DEBUG

#ifdef HA7E_NO_DEBUG
:return sun();
#endif HA7E_NO_DEBUG

:end
[/highlight]

Wenn ich im EibPC Code HA7E_NO_DEBUG definiere, dann sollten eigentlich alle Debugs rausfliegen und überall sun() erscheinen. Das wirkt sich aber so aus, das der EibPC dann nur noch Fehler vom HA7E liest (85°)
Definiere ich das nicht, so wird offensichtlich die Last beim EibPC so hoch, das der Webserver nicht mehr funktioniert.

[enertegus]

Mir ist jedoch zu Ohren gekommmen, das nach einem update auf die 3.009 ggf. die 15a.lib nicht mehr läuft. Sind hier weitere Erfahrungen mit der 15a.lib und der 3.009 gemacht worden und Lösungen vorhanden?
[/FONT]

Bernd hat da wohl was zu geschrieben, wir selber können aber nur für unsere Libs Support leisten - und die sollten auch die Temperaturen auf den Bus bringen. Die Debuginfos sind da so eine Sache. Im Normalbetrieb stören die nur und sind ohne den Programmierbackground nicht zu verstehen.

[rennsemmel]

Auch wenn mich das Thema frustriert, Danke für Eure Response.

Ich habe das Gefühl da ist noch etwas anderes im Argen. Warum frieren Werte (nacheinander) ein?
Ist das bisher nur mit den BMX libs in Zusammenhang aufgetreten und was könnte der Grund hierfür sein? Kann der Wert im Sensor einfrieren?

@energetus
Eure nicht robuste lib war der Grund warum ich auf die bmx gewechselt bin (es wurden nicht immer alle Sesoren initialisiert). Kann ich aber nachvolziehen, wenn Ihr nicht die bmx lib warten könnt. Die bmx lib lief zunächst Wochenlang. Ich werde die weitere Funktion noch ein paar Tage beobachten. Wenn ich dann wieder Zeit habe, werde ich wohl auf die Enertex lib zurück gehen, In jedem Fall denke ich, dass ich eine Sicherung einbauen werden muss. Das wird mich wohl ein paar Wochen beschäftigen aber anders lernt man das ja nicht.
Was mir dann noch fehlt ist, dass das, wer auch mmer notwendig im System einen Reset erfolgt, bis alle Sensoren laufen. Meine ersten Versuche mit der enertex lib die RS232 zu resetten sind damals fehlgeschlagen.

Eigentlich nicht mein Wunsch aber kann man auf ältere Firmwareversionen z.B. von einer 3.000 auf eine 2.x zurück gehen?

@Bernd
auf der einen Seite schreibst Du die 15e läuft und auf der anderen Seite läuft sie nicht mit der Debug Funktion aktiv oder nicht aktiviert. Also unterm Strich läuft die 15e nicht? Hab ich da etwas falsch verstanden?

Falls ja, wo bekomme ich die 15e her?

PS: Nur nochmal zur Verdeutlichung. Ich nutze die 15a debug Funktionen nicht. Ich habe eigene Zeilen code mit Sendudp in das Mainprogramm geschrieben um alle Temperaturwerte, Sollwerte und Stellgrößen zu loggen.Dies geschieht alle 5 sec.

[rennsemmel]

Werte sind heute morgen gegen 4 Uhr wieder nacheinander eingefroren...
Bin jetzt erst mal die nächsten 2 Wochen offline.

[rennsemmel]

RS232 / HA7E stürtzt ab

Nach 10 Tagen wurden immer noch keine neuen Werte ausgelesen (Keine Selbstheilung).

Was scheinbar hilft: Ich habe gestern Abend einen RS232 Reset durchgeführt. Der Reset wurde mit Hilfe des in der 15a.lib eingebauten "Schalters" über eine GA und dem Senden dieser GA über die ets ausgeführt. Der eibPC wurde NICHT geresettet.
Nun werden die Werte wieder ausgelesen. Das Überwachen der Temperaturwerte auf Veränderung und einen daraus resultierenden Reset scheint also ein Workaround zu sein...

Welche Erfahrungen sind mit der RS232 bzw HA7e gemacht worden? Ist es der Adapter oder die RS232 die "abstürzt" und weiss man, was dazu führen kann, bzw wie es verhindert werden kann?

[enertegus]

Welche Erfahrungen sind mit der RS232 bzw HA7e gemacht worden? Ist es der Adapter oder die RS232 die "abstürzt" und weiss man, was dazu führen kann, bzw wie es verhindert werden kann?

Wir haben den Reset seinerzeit eingebaut, da manchmal die RS232 Buffer im EibPC und HA7E nicht mehr sauber synchron waren - das kann dann passieren, wenn man zu schnell ausliest. Letztlich spielt da auch etwas das Timing im EibPC Kernel eine Rolle.

[rennsemmel]

das kann dann passieren, wenn man zu schnell ausliest. Letztlich spielt da auch etwas das Timing im EibPC Kernel eine Rolle.

Also kann das immer wieder mit jeder lib/code pasieren oder wie ist das in der enertexOneWire.lib sichergestellt, dass nicht "zu schnell" ausgelesen wird?

Da sich beim Code review der lib's von BMX und enertex viele weitere Fragen aufgetan haben, denke ich, ich mache hierzu einen neuen Thread auf, die sich speziell mit der enetexOnewire.lib (und der RS232) beschäftigt.

[MrKNX]

Hi Leute,
hat jemand von euch zuverlässig einen bzw. mehrere 1-Wire VOC Luftqualitätssensoren - Sensoren / Fühler Sensoren im Einsatz?