Neues Modul: EQ3 Bluetooth Thermostat (10_EQ3BT)

[Gasmast3r]

Das sowieso, kenne ich ja noch vom anfang

[g-dave]

Kann mich erst einmal nicht mehr beim Testen beteiligen, aufgrund einer drastischen Hardware-Minimierung im ganzen Haus, musste auch der Satelliten-Pi weichen, 10 Meter USB-Verlängerung erledigt den job jetzt .
Dennoch danke für das bugfixing!!!

Gruß
Dave

[Gasmast3r]

Code Auswählen Erweitern


sh: 1: Syntax error: Unterminated quoted string
sh: 1: Syntax error: Unterminated quoted string
sh: 1: Syntax error: Unterminated quoted string
sh: 1: Syntax error: Unterminated quoted string


[CoolTux]

Na da muss ich wohl noch mal ganz genau schauen. Danke Dir

[IT-Fuzzi]

Hallo,

zunächst einmal vielen Dank für dieses super Modul und die ganze Arbeit damit!!! Das war für mich der Grund zum Einstieg in FHEM und seitdem bin ich süchtig
Ein, zwei Fragen bzw. Anregungen hätte ich jedoch.

Mir ist aufgefallen, dass durch

Code Auswählen Erweitern

Set <thermostat> updateStatus
ein weiterer "Updateprozess" gestartet wird, der ebenfalls alle 3 min neu ausgelöst wird. Eventuell dadurch, dass hier die gleiche Methode verwendet wird wie beim automatischen Update bzw. diese sich am Ende wieder selbst aufruft?! Meiner Meinung wäre das noch ein kleiner Fehler im Modul.
Hier setzt auch direkt eine weitere Frage an. Wäre es möglich diesen Timer direkt im FHEM zu ändern bzw. komplett zu deaktivieren, wohl wissend dass dann der anzeigte Status in FHEM von der Realität abweichen kann? Derzeit sind im Modul ja ~ 3 min eingestellt, bzw. wenn ich das richtig lese 140 Sek + rand(60)?

HomebridgeMapping funktioniert bei mir auch super, jedoch kann ich die Temperatur auf meinem iOS Device lediglich in ganzen Schritten ändern nicht 0,5 Schritten. Ist das normal?

Code Auswählen Erweitern

TargetTemperature=desiredTemperature::desiredTemperature,minValue=10,maxValue=25,minStep=0.5,nocache=1

Viele Grüße und Dank nochmal 

[dauergast]

[...]
HomebridgeMapping funktioniert bei mir auch super, jedoch kann ich die Temperatur auf meinem iOS Device lediglich in ganzen Schritten ändern nicht 0,5 Schritten. Ist das normal?

Code Auswählen Erweitern

TargetTemperature=desiredTemperature::desiredTemperature,minValue=10,maxValue=25,minStep=0.5,nocache=1

Viele Grüße und Dank nochmal 

Nein, das ist nicht normal! Bei mir funktioniert es in 0,5 Schritten, so wie durch den Parameter "minStep=0.5" festgelegt.
Vielleicht liegt es bei Dir daran, dass Du eine falsche Temperatur-Range (10°C - 25°C) vorgibst. Die richtigen und zumindest bei mir funktionierenden Werte sind:

Code Auswählen Erweitern

TargetTemperature=desiredTemperature::desiredTemperature,minValue=4.5,maxValue=29.5,minStep=0.5,nocache=1

[Master_Nick]

Moin! 
Super Modul funktiniert 1A bisher 

Ich hatte ursprünglich gar nicht geschaut, ob es eines gibt in FHEM und hätte es hier mit realisiert: https://github.com/Heckie75/eQ-3-radiator-thermostat

Dort hatte ich gesehen, kann man auch die Sperre nutzen damit das Ventil nur noch auf die extene Steuerung reagiert.
Könnte man das ggf. hier noch einbauen? Ein stück was von "childlock" steht ja schon im Code Habe es mal probiert mittels "set ThermostatName childlock on" tat sich nix *g*

Lock:
https://github.com/Heckie75/eQ-3-radiator-thermostat/blob/master/eq-3-radiator-thermostat-api.md#lock-thermostat

[Master_Nick]

Mhh ich hab gerade irgendwie das Problem, dass trotz Neustart des sshHosts und der FHEM Einheit bekomme ich nur noch Fehler in

Code Auswählen Erweitern


errorCount-setDesiredTemperature
errorCount-updateStatus
errorCount-updateSystemInformation

Und es wird auch nicht mehr übernommen was am Thermostat eingestellt wird oder aber übernommen was ich in FHEM einstelle.

O_o generell empfang eich aber am sshHost das Thermostat weiterhin mit bluetoothctl  - muss ich nun doch mal pairen? ^^

Wenn ich mir den Status vom FHEM Service ansehe sehe ich das hier:

Code Auswählen Erweitern

           ├─8239 sh -c timeout 15 ssh ZeroW 'gatttool -b 00:1A:22:0C:18:D4 -i hci0 --char-write-req --handle=0x0411 --value=031202140F21 --listen 2>&1'
           ├─8240 timeout 15 ssh ZeroW gatttool -b 00:1A:22:0C:18:D4 -i hci0 --char-write-req --handle=0x0411 --value=031202140F21 --listen 2>&1
           ├─8241 ssh ZeroW gatttool -b 00:1A:22:0C:18:D4 -i hci0 --char-write-req --handle=0x0411 --value=031202140F21 --listen 2>&1


Ist es richtig, dass er 3 parallel auf macht? Oder liegt da schon das Problem? (Das ist der Zustand nach Neustart beider Geräte - Pi3 mit FHEM und Pi ZeroW als sshHost)

[CoolTux]

Ging es denn mit SSH schon mal?
Es gibt noch einen Bug in der SSH Umsetzung. Dieser sollte sich aber eher selten und anders zeigen. Leider komme ich aktuell nicht dazu den zu beseitigen.

[Master_Nick]

Ja ich habe es gestern nur mit SSH eingerichtet.

Anders ist für mich nicht machbar Option, da am Pi3 schon ein FlicButton dran ist :-D Und der Device damit zu ist.
Lief auch gut. Heute morgen war aber einmal irgendwie ein Auflauf von gatttools offen. Daher Reboot der beiden Instanzen.

Noch die Logeinträge:

2018.02.20 12:40:23 5: EQ3BT (Wohnzimmer_Thermostat): ssh ZeroW 'gatttool -b XX:XX:XX:XX:XX:XX -i hci0 --char-write-req --handle=0x0411 --value=4128 2>&1'
2018.02.20 12:40:23 4: EQ3BT (Wohnzimmer_Thermostat): gatttool result: connect: Device or resource busy (16)
2018.02.20 12:40:23 5: EQ3BT (Wohnzimmer_Thermostat): gatttool return string: Wohnzimmer_Thermostat|00:1A:22:0C:18:D4|error|setDesiredTemperature|0x0411|4128|setDesiredTemperature failed
2018.02.20 12:40:23 4: EQ3BT (Wohnzimmer_Thermostat): setDesiredTemperature failed (0x0411, 4128, setDesiredTemperature failed)
2018.02.20 12:40:27 5: EQ3BT (Wohnzimmer_Thermostat): timeout 15 ssh ZeroW 'gatttool -b XX:XX:XX:XX:XX:XX -i hci0 --char-write-req --handle=0x0411 --value=031202140C28 --listen 2>&1'
2018.02.20 12:40:30 5: EQ3BT (Wohnzimmer_Thermostat): another gatttool process is running. waiting...
2018.02.20 12:40:31 5: EQ3BT (Wohnzimmer_Thermostat): another gatttool process is running. waiting...

[Master_Nick]

Ich vermute gerade folgendes:

Ich starte auf dem Raspi3, dass die Haupteinheit in meinem Aufbau ist, nach dem Start einen FlicServer - dieser verwendet den internen Bluetooth Stack so, dass dieser nicht mehr für anderes zur Verfügung steht.
Dieser Start dauert aber und ich könnte mir vorstellen, dass hier das Problem liegt und FHEM da zwischen prescht mit dem Versuch das Interface zu nutzen für das Thermostat.

Denn der FlicButton geht gerade auch nicht sauber :-D *EDIT* Korrigiere, dass lag an was anderem.

Tja was auch immer ich tu:

- device neu angelegt
- alles mehrfach neu gestartet (auch das Thermostat)

Es will nun irgendwie gar nicht mehr.

EDIT  So also es läuft wieder... mal sehen ob dieses mal Stabil ^^ ansonsten kommt morgen noch ein weiteres Pi3  zum testen.


Das hier wäre der Befehl zum Locken/Deaktiveren der Tasten am Thermostat:

Code Auswählen Erweitern

gatttool -b XX:XX:XX:XX:XX:XX -i hci0 --char-write-req --handle=0x0411 --value=8001

Und das hier zum Unocken/Aktivieren:

Code Auswählen Erweitern

gatttool -b XX:XX:XX:XX:XX:XX -i hci0 --char-write-req --handle=0x0411 --value=8000


Wenn ich nun wüsste wo ich den einsetzen muss im Modul wäre er drin *g* (Kindersicherung wäre fein).

Interessanterweise öffnet er aber sobald mal eine Aktion nicht klappt einfach mal immer wieder noch eine Instanz von gatttool - soll das so sein? Hatte nun heute morgen richtig viele und jetzt eben 9 Stück.
Block sich das nicht gegenseitig? Macht es hier nicht Sinn, da eh nur eine Instanz auf einem BT-Stack arbeiten kann die Dinge nacheinander ab zu arbeiten, also erst wenn ein failed oder sonstiges zurück kam daraufhin einen neuen Versuch zu unternehmen?

gatttool result: connect: Device or resource busy (16)

Kaum haue ich da mit

Code Auswählen Erweitern

sudo killall gatttool rein kommt:

gatttool result: Characteristic value was written successfully

Wäre es  ggf. auch sinnvoll den Errorcount für jede Aktion wieder zu nullen wenn die Aktion erfolgreich war? Dann könnte man noch einbauen, dass das Device auf ERROR geht wenn wirklich mal sagen wir 40 Fehler in einem Counter aufgelaufen sind, dann würde der User das mitbekommen (Batterie leer, Empfang nicht mehr gegeben oder oder).

Wäre es möglich diesen Timer direkt im FHEM zu ändern bzw. komplett zu deaktivieren, wohl wissend dass dann der anzeigte Status in FHEM von der Realität abweichen kann? Derzeit sind im Modul ja ~ 3 min eingestellt, bzw. wenn ich das richtig lese 140 Sek + rand(60)?

Ich sehe das ähnlich, da es hier keine IST Temperatur gibt und geben wird. Kann man ein dauerhaftes Updaten beschränken auf alle 30 Minuten oder jede Stunde (oder alle 2) oder auf einen in FHEM gesetzten Wert (für den Batteriestand sinnvoll denke ich).
Das würde zum einen die Steuerung einfacher machen, die sich aktuell selber blockiert durch die Updates mittels gatttool die parallel passieren.

Und ich hätte noch diese Log-Meldung:

Code Auswählen Erweitern

PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/10_EQ3BT.pm line 492.


Generell bitte nicht falsch verstehen ich finde es mega, dass dieses Modul exisitert. Vielen Dank für jede Minute der Arbeit die hinein floss!

[Master_Nick]

  Also weil ich jetzt einfach ganz dreißt einen CronJob angelegt habe der alle 5 Minuten jegliche gatttool instanzen killt läuft es echt gut :-D

Da haben wir noch Arbeit zu leisten, dass das Modul nicht jede Menge instanzen startet (tut es auch ohne Fehler als Ursache).

[CoolTux]

Also weil ich jetzt einfach ganz dreißt einen CronJob angelegt habe der alle 5 Minuten jegliche gatttool instanzen killt läuft es echt gut :-D

Da haben wir noch Arbeit zu leisten, dass das Modul nicht jede Menge instanzen startet (tut es auch ohne Fehler als Ursache).

Diese Zombis kommen nur bei ssh. Ich kenne kenne den Fehler und weiß was geändert werden muss. Ich komme nur einfach aktuell nicht dazu. Leider 

[Master_Nick]

Dann teile doch mal dein Wissen, dann schau ich mal, ob ich es machen könnte oder ob es uber ist :-D

[CoolTux]

Im Grunde gibt es die Probleme mur wenn --listen verwendet wird. Im zuge dessen kommt der Befehl timeout zum tragen.
Beim zusammensetzen ist mir aber ein Fehler unterlaufen. Das timeout wird momentan als erster Befehl genommen, das ist aber falsch

timeout 15 ssh bla bla

Damit killt er ja die ssh Verbindung nach 15s, richtig wäre

ssh 'timeout 15 'gatttool bla bla

Damit das gatttool nach 15s gekillt wird.

Code Auswählen Erweitern


if( $sshHost ne 'none' ) {
            $cmd = "ssh $sshHost 'gatttool -b $mac -i $hciDevice --char-write-req --handle=$handle --value=$value";
        } else {
            $cmd = "gatttool -b $mac -i $hciDevice --char-write-req --handle=$handle --value=$value";
        }
       
        if(defined($listen) && $listen eq "listen") {
            $cmd = "timeout ".AttrVal($name, "timeout", 15)." ".$cmd." --listen";
        }



Der Befehl muß also anders zusammen gesetzt werden.