Betaversion der openHAB-Bindings

[rtrbt]

Moin,

Hast du die tinkerforge-2.1.26.jar aus der Java-Bindings-Zip oder aus der openHAB-Bindings-Zip? Mir fällt gerade auf, dass die nicht die selben sind, zweitere sind ein Maven-Bundle. Ich editiere mal meinen Post oben, da linke ich auf die falsche Datei, sorry dafür.

Führe in der Konsole mal

sha256sum /usr/share/openhab2/addons/tinkerforge-2.1.26.jar

aus. Korrekt ist die 22c9d235f1c62c29a4ec4c9d1feccccf0e6f8b33.

Wenn du da etwas anderes rausbekommst, musst du die Datei durch die aus den openHAB-Bindings ersetzen.

[rwblinn]

 

Funktioniert = downloaded tinkerforge-2.1.28.jar (maven) , kopiert ins addon verzeichnis, brickd installiert und openhab restartet.

bearbeitet July 20, 2020 at 16:48 von rwblinn
Update

[rwblinn]

Newbie Frage: wie wird ein Channel Parameter for ein item definiert.

Beispiel Air Pressure:

Number TF_Barometer		"Pressure [%.3f mBar]" { channel="tinkerforge:brickletbarometer:jXZ:BrickletBarometerAirPressure" }

Parameter "Update Interval" wo definieren?
Number TF_Barometer		"Pressure [%.3f mBar]" { channel="tinkerforge:brickletbarometer:jXZ:BrickletBarometerAirPressure" ???}

 

Air Pressure

 

The measured air pressure

Type:	Number:Pressure
UID:	tinkerforge:brickletbarometer:[UID]:BrickletBarometerAirPressure
Read only:	Yes
Unit:	Bar
Range:	0.01 Bar to 1.2 Bar (Step 1e-06 Bar)
Parameters:	Update Interval –

[rtrbt]

Das ist eine gute Frage, ich habe das immer nur über die PaperUI gemacht. Da kannst du sowohl das Item anlegen (blau) als auch den Channel konfigurieren (rot). Wenn du das zwingend über die Textdateien machen willst: Ich habe beim danach suchen diesen Thread gefunden, das sieht so aus als könnte es funktionieren.

Edit: Man sollte das Bild auch anhängen

[rwblinn]

Danke für die info.

Denke der weg über die paperui ist gut, da die things auch über die paperui definiert wurden, wo auch die channels konfiguriert sind/können.

Falls textuelle konfiguration für things, dann is die astro binding ein gutes beispiel wo auch parameter gesetzt werden.

Nächste frage: Node-RED openhab2 nodes

Können diese auch für die Tinkerforge openhab2 bindings verwendet werden?
Habe Barometer Bricklet getestet=OK; LCD20x4 Bricklet=Nicht OK (liefert null)

Welche syntax ist für die openhab2-out node payload zu verwenden? beispiel: LCD20x5 writeline. 

 

[rtrbt]

3 minutes ago, rwblinn said:

Node-RED openhab2 nodes

Was es nicht alles gibt.

3 minutes ago, rwblinn said:

LCD20x4 Bricklet=Nicht OK (liefert null)

Welche syntax ist für die openhab2-out node payload zu verwenden? beispiel: LCD20x5 writeline. 

Auf dem LCD ist dann auch nichts zu sehen?

Soweit ich das sehe, (sind das diese Nodes?) sind die für Items, nicht für Actions. D.h. du müsstest irgendwie ein Item für den Text-Channel des LCDs anlegen und da dann einen String im Format "0,1,Hello World!" reinschreiben.

Wenn du Node-RED benutzen willst kannst du aber alternativ zu den openHAB-Bindings auch die MQTT-Bindings verwenden, Node-RED kommt mit MQTT ziemlich gut klar.

[rwblinn]

Node-RED openhab nodes: wollte mal checken ob diese als alternative zu rules (DSL based on Xtend) verwendet werden können. Node-RED mit Tinkerforge MQTT funktioniert sehr gut.

Rule: test Barometer & LCD20x4

/*
openHAB 2 - Test & learn Tinkerforge Master Brick + Barometer & LCD20x4 Bricklets
Notes:
Barometer update interval is set using the PaperUi > Thing BaroBricklet > Channel Air Pressure
Always check the log after changes: /var/log/openhab2/openhab.log or http://192.168.N.NNN:9001/
Define var (and not val) for variables that are reassigned:
val -> value (a fixed value, not to be changed during runtime)
var -> variable (can be changed during runtime, anytime)
*/

// LCD 20x4 Display airpressure
rule "LCD update airpressure"
	when
		Item TF_Barometer received update
	then
		// Get action objects
		val lcdActions = getActions("tinkerforge", "tinkerforge:brickletlcd20x4:rTS");
		val baroActions = getActions("tinkerforge", "tinkerforge:brickletbarometer:jXZ");
		// Get airpressure
		var Number airPressure = baroActions.brickletBarometerGetAirPressure().get("airPressure");
		airPressure = airPressure * 0.001;
		// Update LCD. The line and pos must be initialized.
		lcdActions.brickletLCD20x4ClearDisplay();
		var line = 0;
		var pos = 0;
		// Time HH:MM:SS
		val lastUpdate = new DateTimeType().format("%1$tH:%1$tM:%1$tS");
		line = 0;
		pos = 20 - lastUpdate.length();
		lcdActions.brickletLCD20x4WriteLine(line as short, pos as short, lastUpdate);
		// Airpressure displayed with 2 digits
		line = 1;
		pos = 0;
		lcdActions.brickletLCD20x4WriteLine(line as short, pos as short, String::format("%1$.2f",airPressure) + " hPa");
end 

liefert INFO hinweise im openhab.log

==> /var/log/openhab2/openhab.log <==
2020-07-22 08:48:52.194 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'tf1.rules', using it anyway:
The method brickletBarometerGetAirPressure(ThingActions) from the type BrickletBarometerActions refers to the missing type Object
The method brickletLCD20x4ClearDisplay(ThingActions) from the type BrickletLCD20x4Actions refers to the missing type Object
The method brickletLCD20x4WriteLine(ThingActions, short, short, String) from the type BrickletLCD20x4Actions refers to the missing type Object
2020-07-22 08:48:52.266 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'tf1.rules'

 

bearbeitet July 25, 2020 at 14:28 von rwblinn
Update rule

[rtrbt]

Die Infos kannst du ignorieren, das ist ein bekanntes Problem. Ich habe aber bisher noch nicht rausgefunden, wo das herkommt.

Edit: Funktioniert die Regel abgesehen von den Meldungen?

[rwblinn]

OK.

Rule funktioniert.

Getestet: Alternativ item update, ohne action, aber mittels sendCommand

rule "System Start"
when
    System started
then
	// LCD backlight on
	// Switch TF_LCDBacklight	"LCDBacklight" { channel="tinkerforge:brickletlcd20x4:rTS:BrickletLCD20x4Backlight" }
	TF_LCDBacklight.sendCommand("ON");
end

// LCD 20x4 Display airpressure using sendCommand
// Number TF_Barometer		"Pressure [%.3f mBar]" { channel="tinkerforge:brickletbarometer:jXZ:BrickletBarometerAirPressure" }
// String TF_LCD			"LCD" { channel="tinkerforge:brickletlcd20x4:rTS:BrickletLCD20x4Text"}
// String TF_LCDClear		"LCDClear" { channel="tinkerforge:brickletlcd20x4:rTS:BrickletLCD20x4ClearDisplay" }
rule "LCD update airpressure sendcommand"
when
	Item TF_Barometer received update
then
	// Time HH:MM:SS
	val lastUpdate = new DateTimeType().format("%1$tH:%1$tM:%1$tS");

	// Get airpressure
	val airPressure = (TF_Barometer.state) as DecimalType;
		
	// Update lcd
	// TF_LCDBacklight.sendCommand("ON"); - see rule System Start
	TF_LCDClear.sendCommand("Clear");
	TF_LCD.sendCommand("0," + (20 - lastUpdate.length()).toString() + "," + lastUpdate);
	TF_LCD.sendCommand("1,0," + String::format("%1$.4f",airPressure.floatValue) + " hPa");
end 

 

bearbeitet July 23, 2020 at 06:53 von rwblinn
Updated rule

[rwblinn]

Nachtrag Node-RED openhab2 nodes.

Erfolgreich getestet barometer & lcd20x4 bricklet. Keine openhab2 rules oder script dateien verwendet. Dashboard mit addon nodes node-red-dashboard.

 

lcdbaro.flow

bearbeitet July 23, 2020 at 10:52 von rwblinn

[StefanOHAN]

Hallo Eric,

ich hätte drei kurze Fragen:

1) Du schreibt auf die Frage von rasby am 25.05.2020

Zitat

"rasby" >>Bei den IO-16 Bricklets werden die Inputs ebenfalls als "Switch" angegeben. Hat das einen bestimmten Grund? Wäre "Contact" keine sauberere Lösung?" 

"rtrbt">>Das liegt daran, dass ich eigentlich alles, was eine boolsche Variable ist auf einen Switch abbilde. Der Generator bekommt es aber nicht hin zu sehen, dass die Channel zumindest read only sein sollten. Ich gebe dir aber recht, dass Contact hier sinnvoller wäre. Setze ich mir mal auf die TODO-Liste.

Wie sieht hier Deine Planung aus ?

Hintergrund meiner Frage, ich will mein Prod-System umbauen. 

Wenn ich die Item Anlege, müsste ich wissen, ob es hier in Zukunft ein Binding geben würde, dass bei dem IO-16 / IO-4 / Industrial In-Bricklets die als Input konfigurierten Channel als Contact darstellen.

 

2) Ich hatte schon mal das Thema Konfiguration der TF Komponenten über eine "Thing-Datei" angesprochen, hattest Du schon die Zeit/Möglichkeit einen kleinen Leitfaden erstellen ?

Die Konfiguration über eine Thing-Datei würde ein "Neu-Aufsetzten" des System (wenn ein Recovery nicht möglich ist) vereinfachen.

 

3) Es gehört jetzt nicht unbedingt hier zu diesem Themenblock.

Aktuell gibt es einen neuen Raspi 4 mit 8 GB HS, dieser hat einen etwas höheren Leistungsbedarf als der Raspi 4 mit 4 GB HS.

Frage: Ist Dir bekannt, ob es zu Problemen kommen kann, wenn die  Spannungsversorgung des neuen Pi-4 mit 8GB-HS über das HAT-Brick erfolgt ? 

Bei Euch in der Beschreibung des HAT-Brick finde ich nur die Aussage 

Zitat

Die integrierte Stromversorgung liefert auch unter großer Last stabile 5V für den Raspberry Pi

Ich vermute es sollte kein Problem sein, oder ? (ich habe an den USB-Ports nur 5 Masterbricks mit diversen TF Bicklets angeschlossen)

viele Grüsse

Stefan

 

[rtrbt]

Moin,

1 hour ago, StefanOHAN said:

Wenn ich die Item Anlege, müsste ich wissen, ob es hier in Zukunft ein Binding geben würde, dass bei dem IO-16 / IO-4 / Industrial In-Bricklets die als Input konfigurierten Channel als Contact darstellen.

Ich muss mal testen, ob das funktioniert, das schiebe ich diese Woche noch ein.

1 hour ago, StefanOHAN said:

2) Ich hatte schon mal das Thema Konfiguration der TF Komponenten über eine "Thing-Datei" angesprochen, hattest Du schon die Zeit/Möglichkeit einen kleinen Leitfaden erstellen ?

Da gibt es bisher noch keine Updates, mein letzter Stand als ich das vor Monaten getestet hatte war, dass aus irgendeinem Grund Things dupliziert werden.

1 hour ago, StefanOHAN said:

Frage: Ist Dir bekannt, ob es zu Problemen kommen kann, wenn die  Spannungsversorgung des neuen Pi-4 mit 8GB-HS über das HAT-Brick erfolgt ? 

Die Spannungsversorgung auf dem HAT schafft theoretisch 4A bei 5V, wird aber bei 3A Dauerlast schon ziemlich heiß. Die Raspberry Pi Foundation schreibt in den Spezifikationen

Quote

• 5V DC via USB-C connector (minimum 3A*)
• 5V DC via GPIO header (minimum 3A*)

* A good quality 2.5A power supply can be used if downstream USB peripherals consume less than 500mA in total.

Daraus könnte man jetzt abschätzen, dass sie für den Pi selbst mit 2A Peak-Strom rechnen. Die USB-Geräte können laut diesem Artikel bis zu 1,2A ziehen, dazu kommt dann noch was du am HAT selbst angeschlossen hast. Für die Bricks und Bricklets sollte jeweils der Stromverbrauch dokumentiert sein. D.h. du kannst dir das für deinen Aufbau durchrechnen, wenn du aber nicht gerade 5*4 + 8 Industrial Dual Relays verbaust und die alle schaltest, sollte das vermutlich gehen. Der Pi sollte wenn du darauf nur openHAB laufen lässt ja auch nicht gerade unter permanenter Volllast sein.

Du solltest aber auf jeden Fall einen flachen Kühlkörper auf den Prozessor des Pis setzen und den ganzen Aufbau mit einem Lüfter kühlen, sonst brennt dir der Pi selbst schon ein Loch in den Tisch.

Gruß,
Erik

[StefanOHAN]

Hallo Erik,

danke für Deine Rückmeldung, bin schon gespannt was bei Deinem Test heraus kommt.

Thema HAT-Brick & Pi4 Stromversorgung

Ich habe kurz überschlagen was die verschieden TF Komponenten in Summen (MAXIMAL) an Strom ziehen würden 

>>HATBrick angeschlossene Bricklets ca 300mA 

>>per USB am Pi angeschlossenen MasterBricks (2) ohne eigenes StepDown-Power-Supply & Bricklets MAXIMAL 250mA 

>>per USB am Pi angeschlossenen MasterBricks (3) mit eigenem StepDown-Power-Supply & Bricklets  MAXIMAL 600mA.  (nur hier habe ich 2x Dual-Relais  angeschossen)

 

Somit dürfte die Versorgung des des Pi4-8GBHS über das HAT-Brick kein Problem sein.

 

Thema Kühlung:

Seit ein paar Wochen hat mein PI3 & HAT-Brick Testsystem einen Kühlkörper vom Typ „Armor-Case-BLOCK-für-Raspberry-Pi3B-Kühlkörper“ (analog wie einer für den Pi4 Eures Partner Rasppishop vertrieben wird).

Um das Hat-Brick noch aufstecken zu können und genügend Abstand zwischen Kühlkörper und HAT-Brick zu haben, habe ich einen "40 poliger GPIO Steckverbinder, durchsteck- und stapelbar" im Einsatz. (so ein 40 polige GPIO Steckverbinder wäre eventuell was als addon für Euren Shop)

Ich musste allerdings etwas kreativ werden um einen festen Sitz des HAT-Brick sicher stellen zu können. Dieser Aufbau läuft seit gut 6 Wochen ohne Störung und ermöglicht es mir bei Bedarf auch einen Lüfter einzusetzen. 

Dieser Aufbau sollte mögliche TemperaturProbleme eines PI4-8GB lösen, vor allem da ich auf dem PI nur Openhab laufen lasse und als OS das optimierte Openhabian zum Einsatz kommt

 

Grüße Stefan

[rtrbt]

Moin,

Hatte ganz vergessen dir zu schreiben. Die Input-Channels auf Contact umzubiegen scheint prinzipiell zu funktionieren, das muss ich jetzt noch dem Generator für alle entsprechenden Bricklets beibringen. Mache ich im Zuge des großen "alle Konfigurationen der Bricklets durchgehen und dabei die deutsche Doku schreiben" gleich mit, wenn ich denn mal dazu komme. Mir ist aber aufgefallen, dass Contacts anscheinend in der PaperUI-Übersicht den aktuellen Zustand nicht anzeigen.

Bezüglich der Kühlung: Du kannst dir ja einen openHAB-Channel für die CPU-Temperatur bauen, dafür habe ich spontan diese Anleitung gefunden. Ich würde aber erwarten, dass es mit dem Kühlkörper keine Probleme gibt.

[StefanOHAN]

Hallo Erik,

 

dann warte ich mit dem Umbau/Umstellung des Prod-System noch etwas, bis klar ist ob Du den Generator hierfür anpassen kannst.

Danke für den Link für einen Channel zur Temperaturüberwachung der GPU/CPU. Auf ähnlicher Basis hab ich für mein OpenHAB 1.8 System eine Überwachung am Laufen, ich sehe aber an dem Beispiel, dass meine Version noch Verbesserungspotential hat 🙂

Zufällig ist heute mein neuer P4 8GB gekommen, ich werde versuchen diese WE mal sein Temperaturverhalten mit dem Kühlkörper zu testen (noch ohne HAT-Brick).

 

viele Grüsse

 

Stefan

 

bearbeitet August 11, 2020 at 12:39 von StefanOHAN

[StefanOHAN]

Hallo Erik

nur wenn es von Interesse ist, die Leerlauf Temperaturen auf dem PI4 B mit 8GB RAM.

Es ist nur das Openhabian-OS mit Openhab installiert. Über einen  "Exec"-Channel werden  die GPU & CPU Temperaturen abgefragt (analog dem Link den Du gepostet hast), es laufen keine Rules.

Der Pi ist in ein Armor-Case-Block Alu-Kühlkörper-Gehäuse eingebaut.

Raumtemperatur  => 29 Grad >> Pi-GPU/CPU-Temperatur ca 46 Grad (ohne Lüfter)

Raumtemperatur  => 26 Grad >> Pi-GPU/CPU-Temperatur ca 42 Grad (ohne Lüfter)

Raumtemperatur  => 29 Grad >> Pi-GPU/CPU-Temperatur ca 33 Grad (mit aktiven Lüfter auf den Gehäuse)

Damit der Pi4 auch unter Last bei diesen Temperaturen einen kühlen "Kopf" bewahren kann, werde ich beim Umstellung auf den PI4, eine temperaturabhängige Lüftersteuerung für den Kühlkörper vorsehen.

viele Grüsse

 

Stefan

[StefanOHAN]

Hallo Erik,

nach dem FW-Update des HAT-Brick trat mein alt bekanntes "sporadische" auftretenden Problem, dass das Astro- & NTP Binding den Betrieb einstellten, häufiger als bisher auf. Aus diesem Grund führte ich einen OS (openhabian 1.5) und Openhab (stabel-Version) Update aus.

Leider trat danach der Fehler mehrfach täglich auf  und ich entschloss mich das Test-System komplett neu aufzusetzen (jetzt mit Openhabian 1.6 und neuer SD-Card, das Testsystem läuft auf einem PI3, das root-System liegt jetzt auf einer USB-HDD).

Auf auf dem komplett neu installierten System, trat das Problem des ASTRO und EXEC-Binding (NTP Bindings war zu diesem Zeitpunkt nicht installiert), alle 6-8 Stunden auf.

Der Fehler tritt bei mir auf, wenn nach einigen Stunden Betrieb das TF-Binding versucht den Masterbrick, der über WIFI angeschlossen ist, wieder online zu nehmen (also wenn die AVM mal wieder eine Kanal-Optimierung durchführt), ob das die Ursache ist weiß ich aber nicht.

Aktuell sind keine Rule's aktiv, es wird nur über das Astro-Binding der Sonnen-Winkel ermittelt, und über das EXEC-Binding wird die PI-Temperatur alle 60 Sec abgefragt. Konfiguriert sind nur die 4 Bricklet die über das WIFI/Masterbrick und die 8 Bicklets die über das HAT-Brick angebunden sind, keine Bricklets/Masterbrick die über USB angeschlossen sind, sind konfiguriert.

Die ersten Stunden nach einem Neustart gibt es keine Probleme auch wenn der WIFI/Masterbrick off/online geht. 

Ein Temperatur Problem des PI kann es nicht sein, der Pi3 hat einen Kühlkörper und einen aktiven Lüfter (per Exec überprüfte CPU-Temperatur ca 36Grad)

Ich konnte den Fehler jetzt soweit eingrenzen, dass anscheinend innerhalb von Openhab die interne zeitliche Steuerung, die in wiederkehrenden Intervallen, Aktionen in Bindings steuert, nicht mehr funktioniert. Alle drei betroffen Binding‘s (ASTRO/NTP/EXEC) führen in definierten Zeitintervallen Aktivitäten aus. Es hilft nur ein Restart von Openhab.

Im Log sind keine Fehlermeldungen außer dem des TF-Binding zu lesen.

Irgendwie scheinen sich die verschieden Bindings gegenseitig zu beeinflussen

Hast Du einen IDEE was die Ursache sein könnte, oder welches Modul in Openhab diese Zeitintervalle steuert  ?

Welche Linux Konfiguration nutzt Du (Pi mit HAT-Brick?), hast Du neben den TF-Binding noch andere Binding's aktiviert ? Hast Du auch Systeme die über einen längern Zeitraum laufen ?

Ich werde jetzt mal das ASTRO-Binding deaktivieren, mal schaun was passiert.

 

Eines ist mir noch aufgefallen:

Bei Konfiguration nach der Neuinstallation ist mir ist aufgefallen, dass die beiden Taster des Dualbutton-Bricklet (V2) sich nicht wie Taster sondern wie Schalter verhalten. Also wenn man den Taster (rechts oder links) 1x betätigt dann bekommt man im Log die Meldung „right_button predicted to become ON“ wenn man den Taster ein zweites mal betätigt bekommt man die Meldung „right_button predicted to become OFF“

Ich bin mir nicht mehr sicher ob dies nun so gewollt war oder nicht ?

 

viele Grüsse

Stefan

bearbeitet August 25, 2020 at 06:55 von StefanOHAN

[rtrbt]

Moin,

1 hour ago, StefanOHAN said:

Hast Du einen IDEE was die Ursache sein könnte, oder welches Modul in Openhab diese Zeitintervalle steuert  ?

Nein, das ist mir absolut unklar. Die Zeitsteuerung läuft über einen Scheduler von openHAB, ich würde aber nicht erwarten, dass der das Problem ist. Teste mal folgendes:

Aktiviere mal das Trace-Logging für alle involvierten Bindings, also mindestens Astro und Tinkerforge. Den Paketnamen des Astrobindings bekommst du über

list -s | grep binding

in der Karaf-Konsole raus. Dann kannst du das Trace-Logging mit

log:set TRACE [binding-name]

aktivieren. (Das kennst du ja schon für das Tinkerforge-Binding )

Ich hoffe, dass du dann nicht so sehr mit Ausgabe geflutet wirst, dass man das nicht die paar Stunden laufen lassen kann.

Wenn du dann in dem Zustand bist, dass ein anderes Binding hängt, würde mich das Log interessieren (also openhab.log aus userdata/logs/), im Idealfall machst du das vor dem ganzen Test einmal leer.

Außerdem kannst du, wenn das ganze hängt, in der Karaf-Konsole

shell:threads

ausführen und die Ausgabe mit schicken. Der Befehl gibt aus, was alle openHAB-Threads gerade tun.

Eine Idee, was dein Problem ist hätte ich noch: Wenn du Regeln hast, die in bestimmten Umständen lange blockieren (eventuell auch nur bei seltsamen Zuständen wie dieser Kanaloptimierungsgeschichte der Fritz-Box), kannst du damit eventuell Teile von openHAB blockieren. Siehe hier.

Falls wir das Problem bis dahin nicht raushaben, werde ich bei nächster Gelegenheit mal einen vergleichbaren Aufbau hier hinstellen, vielleicht bekomme ich das ja reproduziert.

1 hour ago, StefanOHAN said:

Welche Linux Konfiguration nutzt Du (Pi mit HAT-Brick?), hast Du neben den TF-Binding noch andere Binding's aktiviert ? Hast Du auch Systeme die über einen längern Zeitraum laufen ?

Ich habe hier zum testen der Bindings immer nur ein lokales openHAB auf dem PC laufen, es gibt aber ein paar Systeme von denen ich weiß, die seit Monaten problemlos laufen, das von meinem Kollegen auch mit dem Astro-Binding. Er hat seinen Stapel aber über Ethernet angebunden.

1 hour ago, StefanOHAN said:

Eines ist mir noch aufgefallen:

Bei Konfiguration nach der Neuinstallation ist mir ist aufgefallen, dass die beiden Taster des Dualbutton-Bricklet (V2) sich nicht wie Taster sondern wie Schalter verhalten. Also wenn man den Taster (rechts oder links) 1x betätigt dann bekommt man im Log die Meldung „right_button predicted to become ON“ wenn man den Taster ein zweites mal betätigt bekommt man die Meldung „right_button predicted to become OFF“

Ich bin mir nicht mehr sicher ob dies nun so gewollt war oder nicht ?

Das ist im Moment noch so gewollt, die Bindings generieren für alle boolschen Channel SwitchTypes, die Contacts für boolsche Channel die nur lesbar sind kommen vermutlich mit der nächsten Beta.

[StefanOHAN]

Hallo Erik,

danke für die schnelle Antwort und Deine Vorschläge.

Ich test gerade mal ohne dem Astro Binding und schau wie lange das problemlos funktioniert.

Aktuell (also  auch als das ASTRO-Binding noch aktiv war) waren keine Rules aktiv, die hab ich bewusst weg gelassen.

Ich werde das mit dem 

log:set TRACE [binding-name]

für die beteiligten Bindings in ein oder zwei Tagen testen, ich will vorerst mal sehen wie sich das System ohne Astro verhält.

Von der Log Menge sehe ich jetzt kein Problem, da ich zwischenzeitlich über eine usb-SSD arbeite (ich will  damit verhindern, dass durch das erhöhte Log Aufkommen nicht die SD-CARD Probleme verursacht).

Kannst Du bitte mal Deinen Kollegen Fragen (der mit der PI / Astro / LAN-Masterbrick) arbeitet, welche OS-Version und Openhab-Version einsetzt ?

Danke im Voraus

 

viele Grüsse

Stefan

[batti]

Hi,

ich nutze openHAB 2.5.7-1 auf einem Ubuntu bionic.

VG

[StefanOHAN]

Hallo Erik, hallo Batti

@ Danke Batti für die Info, ich muss mal schaun ob ich evtl auf Ubuntu umsteige.

Erik,

als am Astro liegt es anscheinend auch nicht, gestern Abend nach ca 16 Laufzeit hat der Exec wieder den Dienst eingestellt.

Ich füge den output des shell:thread bei (ich hab den output per copy & paste in Notepad+ eingefügt und als txt abgespeichert wenn es Probleme beim Öffen geben sollte)

Nachdem ich den shell:thread erstellt habe, habe ich log:set TRACE für folgend Bindings aktiviert (ASTRO ist noch nicht installiert), 

org.openhab.binding.tinkerforge

org.openhab.binding.exec

org.openhab.core.binding.xml

es war noch das Binding für den LogReader installiert, hierfür habe ich aber den Trace nicht aktiviert. Um 23 Uhr erfolgte dann der restart des System.

Sobald der Fehler wieder auftaucht, werde ich nochmal das Ergebnis des shell:thread und den Auszug der Logfile's senden.

Bis jetzt sind noch immer keine Rules aktiv.

 

Eine andere Frage: Ich hab noch einen PI2 rum liegen und hab mir überlegt dort auch Openhab für ein minimalisiertes Notfallsystem zu installieren. Wenn ich auf diesem Pi den TF Dämon installiere und remote auf die TF Komponenten zugreife die an einem anderen Pi aktiviert sind auf dem ebenfalls Openhab läuft,  sollte es doch kein Problem sein die Sensor / channel-trigger Daten zu überwachen. Also nicht über den zweiten Pi aktiv Aktionen auf den TF Komponenten shellthreads-von-20200825-2236.txtausführen sondern nur "lauschen" oder ?

 

viele Grüsse

Stefan

bearbeitet August 26, 2020 at 06:26 von StefanOHAN

[rtrbt]

Moin,

Die shell:threads-Ausgabe ist sehr interessant, anscheinend passiert da folgendes:

Ich habe einen Heartbeat-Mechanismus der alle 90 Sekunden prüft ob die Bricks und Bricklets noch erreichbar sind. Falls ein Timeout auftritt (z.b. weil dein WiFi-Stapel weg ist) ziehe ich den nächsten Heartbeat vor, damit er sofort prüft, was alles noch da ist. Das Vorziehen funktioniert aber so, dass ich den regelmäßigen Heartbeat abbreche und stattdessen dem Scheduler einen neuen gebe, der sofort los läuft (und dann wieder 90 Sekunden später).

Jetzt kann es, wenn das Timing schlecht ist, passieren, dass ein Timeout passiert, einer der ThingHandler-Threads (davon scheint es 5 zu geben) den Heartbeat vorzieht, ihn ausführt und währenddessen der nächste ThingHandler-Thread auch einen Timeout behandelt. Dann laufen auf einmal zwei Heartbeats parallel. Das ganze kann noch öfter passieren und dann hast du alle 5 ThingHandler-Threads die den Heartbeat ausführen.

Das ist an sich kein Problem, aber der Heartbeat funktioniert so, dass er für jeden Brick und jedes Bricklet dem Scheduler einen Task gibt der den Status prüft und dann wartet bis die alle durch sind. Der Scheduler hat jetzt aber keine Threads mehr übrig die diese Tasks ausführen können, weil ja alle bereits im Heartbeat stecken und auf "ihre" Status-Prüf-Tasks warten. Ab dem Punkt hängt dann die ganze Thing-Behandlung.

Teste mal bitte die angehangene Version, die sicherstellen sollte, dass nur einer der Timeouts einen Heartbeat auslösen kann.

 

1 hour ago, StefanOHAN said:

Eine andere Frage: Ich hab noch einen PI2 rum liegen und hab mir überlegt dort auch Openhab für ein minimalisiertes Notfallsystem zu installieren. Wenn ich auf diesem Pi den TF Dämon installiere und remote auf die TF Komponenten zugreife die an einem anderen Pi aktiviert sind auf dem ebenfalls Openhab läuft,  sollte es doch kein Problem sein die Sensor / channel-trigger Daten zu überwachen. Also nicht über den zweiten Pi aktiv Aktionen auf den TF Komponenten shellthreads-von-20200825-2236.txtausführen sondern nur "lauschen" oder ?

Die Bindings nehmen immer an, dass sie volle Kontrolle über die Bricks und Bricklets haben, d.h. "offiziell supported" ist das nicht. In der Theorie sollte es aber funktionieren, wenn du die Konfiguration der Bricks und Bricklets in beiden openHAB-Instanzen synchron hältst, aber es ist gut möglich, dass dann trotzdem seltsame Effekte entstehen wenn beide openHAB-Instanzen versuchen ein Bricklet umzukonfigurieren o.Ä..

tinkerforge_openhab_bindings_2_0_0.zip

[StefanOHAN]

Hallo Erik,

ich werde heute Abend das Spezial-Test-Binding einspielen und gleich noch das Astro-Binding aktivieren.

viele Grüsse

Stefan

bearbeitet August 26, 2020 at 13:22 von StefanOHAN

[StefanOHAN]

Guten Morgen Erik,

ich hab gestern Abend Dein Spezial-Test-Binding eingespielt.

Um zu sehen ob alles funktioniert, habe ich wieder alle TF-Bricklets, das NTP / ASTRO / EXEC Binding in die Konfiguration aufgenommen. Ebenfalls alle Rule's die ich im Frühjahr zum Testen der verschieden Funktionen erstellt habe sind wieder aktiv.

Seit gestern Abend (ca 22Uhr) läuft wieder alles. Bis jetzt habe ich keine Fehler gesehen. Ich hatte heute auch schon ein paar WLAN-Kanal-Wechsel und damit WIFI/Masterbrick reconnect, bis jetzt ohne Probleme.

Ich werde Dir berichten ob es Probleme gibt oder nicht.

Zu meiner Frage Pi2 und Abfrage FT Koponenten die über einen anderen PI in Openhab eingebunden ist. Nachdem ich feststellen muss, dass der P4 doch relativ warm wird (mit montierten Kühlkörper) werde ich beim Umbau die Konfiguration entzerren.

Das HAT-Brick kommt auf dem PI2, dort wird nur ein minimalisiertes Raspian und der FT-Treiber laufen. Auf dem PI4 wird dann openhab installiert. Der Zugriff auf das HAT erfolgt remote, die anderen MasterBrick werden wie bisher per USB am Pi4 mit der Openhab Installation angeschlossen. Das werde ich aber erst mal bei Gelegenheit testen.

 

noch mal Danke für deine schnelle Reaktion 

viele Grüsse

Stefan

[StefanOHAN]

Guten Morgen Erik,

kurzer StatusUpdate

Das System läuft jetzt seit über einen Tag ohne Ausfallerscheinungen des Astro/NTP/Exces, alle FT Komponenten funktionieren, die Rules laufen, und das Masterbrick(WIFI) wurde mehrfach ohne Probleme reconneted.

Viele Grüsse

Stefan