Hallo HJH,
dazu waere es wuenschenswert zu wissen, unter welchen Bedingungen Du das festgestellt hast. Ich meine also folgende Zustaende:
IPS laeuft als Dienst (logisch)
keine Console offen
Console offen, aber keine Baumstruktur
Console offen, Baumstruktur offen
Wie das ganze mit dem Designer aussieht, weiss ich leider nicht, da ich diesen nicht verwende.
Hallo Uwe,
die Console läuft bei mir als Kontrollzentrum ständig. Um ein paar Variablen nachzusehen entwerfe ich nicht extra eine Designer/Dashboard Anwendung.
Also: Console läuft in der Baumstruktur-Ansicht, kein Designer.
Gruß
HJH
Hi Torro,
ich hoffe Du klärst uns Unwissende auf, wie das geht. 
Mittlerweile hat die Diskussion sich in eine neue Richtung entwickelt, Klasse Community.
Hilfreich wär dann ´ne Multigrafik zum untermauern dieser These: Systemauslastung in Verbindung mit der Fehlerquote.
Frage?
Als Anwendungstip zwischendurch, kann man das minimieren indem man die Werte mit Pausen nacheinander ausliest?
mfg
BerndJ
Die brauch ich nicht. Das ist Verhalten ist zuverlässig nachvollziehbar.
Die einzige Schwierigkeit liegt darin, nicht gleich zuviel Last zu erzeugen, sonst setzt IPS komplett aus.
Bei Temperatursensoren ist ein fehlender Messwert ja auch nicht wirklich problematisch. Richtig ärgerlich ist, dass das TMEX-Modul bei zwei gleichzeitig hängenden Timern vollständig blockiert.
Man kann das in der Timer-Übersicht gut beobachten. Zur der Abfrage wird das Intervall eines Sensors auf 300 gesetzt. Wenn zwei Sensoren dauerhaft ein Intervall 300 haben, muss das TMEX-Modul zurückgesetzt werden.
Hallo BerndJ,
nein, das Abfrageintervall gilt für alle aktivierten Kanäle. Abgesehen davon liegt es ja in meiner Absicht alle Kanäle möglichst of auszulesen, um Spitzenwerte zu erfassen.
Gruß
HJH
Hallo robi,
also ich habe 47 „strong-accessing“ Warnungen (sind keine Fehler) innerhalb von 8 Tagen. Das sehe ich bei meinem Netz also voellig unrelevant an.
Bei Temperatursensoren ist ein fehlender Messwert ja auch nicht wirklich problematisch. Richtig ärgerlich ist, dass das TMEX-Modul bei zwei gleichzeitig hängenden Timern vollständig blockiert.
Man kann das in der Timer-Übersicht gut beobachten. Zur der Abfrage wird das Intervall eines Sensors auf 300 gesetzt. Wenn zwei Sensoren dauerhaft ein Intervall 300 haben, muss das TMEX-Modul zurückgesetzt werden.
das verstehe ich jetzt nicht. 300 sind doch 5 Minuten? Wenn man weniger ansetzt, passiert das wohl nicht?
Hallo BerndJ,
ist aber Off Topic 
linux:/var/log/ips/grep strong * > anzahl
linux:/var/log/ips/o anzahl
anzahl lines 1-30/47 63%
also vorher natuerlich die betreffenden Log Files auf ein Linux System kopiert…
Hallo Hans-Joerg,
auf dem Rechner direkt, sicherlich, oder?
Dann mach mal folgendes:
ips Dienst stoppen
starte den Taskmanager
ips Dienst starten
Console starten
Baumansicht starten
und dabei immer schoen Deine Systemlast beobachten, dann weisst Du auch, wo Dein Problem ist. So habe ich es bei mir zumindest ausgemacht.
Nein, die Intervalle im Timer-Informationsfenster sind in Millisekunden angegeben. 200 ms scheint die Wartezeit von IPS für eine One-Wire Abfrage zu sein. Da liess mich entweder meine Erinnerung im Stich oder das Intervall wurde inzwischen verkürzt.
Vor einigen Versionen wurden die Einträge der Timer-Übersicht noch automatisch aktualisiert. Da konnte man gut beobachten wie das Intervall beim Auslesen verändert wird.
Hallo Robert,
jetzt verstehe ich, was Du meintest.
steiner hatte geschrieben, dass sie in Bezug auf den 2408 noch etwas gemacht haben, dass dort das Procedere schneller ist. Ansonsten weiss ich nur, dass die V2 anders arbeitet wie die V1. Bei dieser wurden Warnungen gar nicht „bekannt“ gegeben.
Hallo Uwe,
nicht ich bin es, der ein Problem hat, sondern IP-Symcon. Die Systemlast liegt irgendwo zwischen 9% und 15%.
Trotz dieser geringen Systemlast geht praktisch jeder 2. Wert verloren b[/b].
Gruß
HJH
Hallo Hans-Joerg,
dann erklaere mir doch bitte mal, weshalb das bei mir nicht der Fall ist? Und ich behaupte mal, dass ich wesentlich mehr 1-Wire ICs im Einsatz habe als Du.
Die Systemlast liegt bei mir uebrigens bei 3 Prozent.
Zum Thema grep: MSYS (MSYS | MinGW) installieren und schon kann man die Windows-Konsole mit diversen Linux-Befehlen füttern. Weitere Befehle (eigentlich sinds ganz normale CLI-Programme) gibts auch einzeln zum Download.
Das ist nun wirklich nicht zu übersehen.
Bei allen sonstigen Verbesserungen, in Sachen One-Wire ist IPS in der Version 2 definitiv schlechter geworden!
Hallo robi,
solche Global Behauptungen nuetzen niemand etwas. Wenn man dies meint, dann gehoeren da auch entsprechende fundierte Messergebnisse dazu.
Ich kann dies derzeit noch nicht sagen, da ich aussagefaehige Messergebnisse nocht vorliegen habe, dazu fehlt mir im Moment die Zeit. Aber ich werde mich dieser Sache mal demnaechst annehmen.
Hallo,
vielleicht mal noch ein Erlebnis von heute fuer diejenigen unter uns, die diese Fehler haben.
Ich wollte heute einen Feuchtesensor im Bad installieren und musste deshalb dort die Leiterplatte im Wandgehaeuse (alte Bauart) gegen eine neue Platine austauschen. Nachdem das erstmal erledigt war, habe ich im IPS den neuen Tempsensor installiert und siehe da, auf einmal habe ich auch bei einigen Sensoren diese „strong ace…“ Fehler. Interessanterweise hat auch der neue Tempsensor den Wert falsch gebracht, wenn er ihn mal gebracht hat, und zwar immer nur Minusgrade. Das konnte ja nicht sein.
Also im IPS das Polling bei diesem Sensor deaktiviert und sofort waren die Fehler weg. HHm…Alte Platine dran … kein Problem.
Also habe ich den Tempsensor auf der neuen ausgeloetet und einen neuen rein - und siehe da, Messung gehen und es kommen auch keinerlei Fehler. Ich habe also wieder den Zustand wie vorher.
Der Tempsensor hat also offenbar den Fehler verursacht. Er ist im Netz suchbar und wird gefunden. Er gibt Messwerte ab, die aber offenbar falsch waren. Und er verursacht diese „strong accessing“ Fehlermeldungen auf dem BUS, und reisst offenbar auch gleich auf dem gleichen BUS-Element weitere Sensoren mit in diesen Fehlerstatus.
MSR-Junky hat in seinem Keller auch solche Fehlermeldungen und wir haben offenbar einen (auch Temperatur) Sensor ausgemacht, der die Ursache sein koennte. Er will das ganze morgen mal nachstellen und testen, mal schauen, was bei ihm dabei rauskommt.
Vielleicht koennte der eine oder andere mit diesem Fehler das auch mal pruefen.
Hallo Torro,
diese Geschichte kenne ich.
Ich hatte mal einen DS18B20, der machte auch solche Bus-Fehler, aber nur bei ca 1 Grad.
Aber komm mal erst mal drauf…
Hallo an alle,
Klasse, gemeinsame Fehlerlokalisierung in der Gruppe; wir kommen der Ursache näher.
Kann man in irgendeiner Form das Herstelldatum erkennen?
Vielleicht haben die in ihrem Fertigungsprozeß etwas geändert oder die Maske bei der Chip Herstellung.
Mfg
BerndJ
Hallo Bernd,
ich wuesste nicht, wie. Auch anhand der Seriennummer ist kein Rueckschluss moeglich.
Hallo an Alle,
Randbemerkung: Ich habe zwar diese Fehler immer wieder zwischendurch, aber geben meine 6 Stück DS18B20 keinerlei falschen Werte wieder! (stets korrekte Werte)