Entwicklung virtueller Raumtemperaturfühler

Deutsche Foren Software
#1

Hallo zusammen, ich bin jetzt zwar ganz frisch im Forum, aber möchte das Thema noch einmal aufmachen.

Ich bin vor ein paar Monaten von FHEM zu Homegear mit Openhab gewechselt und habe aktuell Stellantriebe von MAX! im Einsatz. Der Wechsel zu Homegear/Openhab war u.a. darin begründet, dass ich in Zukunft gerne auch AskSin Geräte einsetzen möchte. Im ersten Schritt möchte ich die MAX! Stellantriebe durch Temperatursensoren ergänzen, damit die Temperatur nicht direkt am Heizkörper gemessen werden muss.
Da die MAX! Serie von EQ3 gerade eingestellt wird/wurde sind Wandthermostate zum einen schwer zu bekommen, zum anderen finde ich Homematic/AskSin Sensoren, welche z.B. auch die Lufttemperatur liefern können eigentlich interessanter.

Lange Rede kurzer Sinn, ich persönlich habe daher Bedarf an einer Umsetzung der virtuellen Wandthermostate (ähnlich wie bei FHEM) und vielleicht auch einige andere, die nun keine Wandthermostate mehr kaufen können, aber noch Stellantriebe haben usw.

Den von @Flole beschriebenen Ansatz, sich die Implementierung von FHEM abzuschauen und ggf. nachzubauen finde ich interessant und würde mich auch selbst daran wagen wollen.
Allerdings muss ich sagen, dass ich wenig bis gar keine Ahnung von PERL (FHEM Vorlage) und C/C++ habe. Mit Java kann ich schon eher umgehen, wenn auch nur rudimentär. Es wird also voraussichtlich einiges an Zeit in Anspruch nehmen, bis ich das hinbekommen habe und ein paar Tipps zum reinkommen wären sehr hilfreich. Von daher, wenn jemand weiteres Interesse hat das umzusetzen, dann immer gerne :slight_smile:

Nichtsdestotrotz habe ich die vorhandenen Quellcodes mal überflogen. In HomematicBidCos gibt es bereits ein virtuelles Gerät in den C++ Quellen. Mein Ansatz wäre daher, mir die Implementierung dort anzuschauen und das für die MAX! Familie ähnlich umzusetzen. Ich bin mir bisher nur nicht sicher, wie das Nachrichtenpaket zusammengebaut werden muss. In den FHEM Codeschnipseln von Flole sieht man, dass FHEM die Nachricht durch eine Funktion im Modul CUL_MAX zusammenbaut. Gibt es ähnliche Funktionen bereits bei Homegear bzw. Homegear-MAX oder müsste dieser Teil ebenfalls neu geschrieben werden?

Vielleicht wäre @sathya so nett mir ein paar Hinweise zu geben, von wo aus ich mich am besten einarbeite bzw. vielleicht gibt es auch irgendwo eine Dokumentation die ich lesen kann aber bisher nicht gefunden habe.

Viele Grüße
Kevin

1 Like
Auf WINDOW_SWITCH_RECEIVER schreiben
MAX! Wandthermostat per CUL emulieren
#2

Ergänzung:
Ich habe inzwischen diesen Post gefunden: (Homematic Wettersensor emulieren)
Dort wird der virtuelle HM-CC-TC erwähnt, welcher in HomematicBidCos bereits implementiert ist. Sind für die MAX! Familie auch die entsprechenden Vorkehrungen getroffen, sodass ich den virtuellen HM-CC-TC ebenfalls als Vorlage nehmen kann oder muss noch mehr getan werden?

Außerdem verstehe ich calculateCycleLength bzw. calculateLastDutyCycleEvent noch nicht. Ich vermute (befürchte), dass es dort um Berechnungen geht, die für das Timing der Funknachrichten relevant sind? Kann die ggf. übernehmen oder muss das für MAX! neu geschrieben (erstmal ermittelt) werden?

VG
Kevin

#3

Hallo Kevin,

hast du dir mein Pull Request auf Github mal angeschaut? Ich habe das ganze leider nie wirklich getestet und es gibt da wohl noch Bedarf nachzubessern aber grundsätzlich sollte es funktionieren (mit minimalen Änderungen).

Vielleicht hilft dir das weiter

Flole

1 Like
#4

Hallo Flole,

danke für den Tipp. Dein Pull Request war mir zwar aufgefallen, aber ich hatte es noch nicht im Detail angeschaut, das habe ich jetzt nachgeholt und deine Anpassungen auch mal bei mir eingebaut. Dann werde ich das zunächst testen und wenn es mit dem Fensterkontakt läuft, versuche ich es für den Wandthermostat zu adaptieren.
Hast du noch einen Tipp für mich wie ich das virtuelle Gerät anlegen kann? Im Admin-UI läuft ja immer die Suche über den CUL etc. und im CLI gibt es für MAX soweit ich weiß auch keine Option dazu?
Und bzgl der Device Description muss ich mal schauen, wie man die XML Datei dazu aufbaut.

Du hast den Code direkt in MAXCentral eingebaut, während Sathya beim virtuellen HM–CC-TC eine eigene Klasse angelegt hat. Gibt es dafür einen speziellen Grund?

#5

Ein virtuelles Gerät anlegen brauchst du glaub ich nicht. Das ganze funktioniert natürlich nur mit dem CC1101, bzw. ist zumindest dafür gedacht. Die device Description brauchst du auch nicht. Warum ich da was gemacht hab weiß ich nicht mehr, ist alles schon länger her und hat mich seitdem auch nicht so wirklich interessiert, ich muss erstmal dazu kommen meine Kontakte anzubringen bevor ich mich darum kümmer das irgendwas passiert wenn sie eine Änderung erkennen.

1 Like
#6

Ah ok. Dann hatte ich den alten Post falsch verstanden. Das bedeutet, was du damals programmiert hast schafft die Möglichkeit auf den Channel “Window Switch Receiver” vom physisch vorhandenen Stellantrieb zu schreiben. Das ist ja eigentlich noch eleganter als der Umweg über ein virtuelles Gerät.

Also würde es reichen, wenn ich irgendeine Quelle habe die auf den Channel gelinkt wird und dort schreibt?
Einen Stellantrieb habe ich hier und CC1101 Modul ist auch gerade eingetroffen. Dann löte ich gleich die Stiftleiste an und teste das mal.

1 Like
#7

Ob das reicht kann ich dir nicht sagen, die Änderungen verbinden erstmal nur ein virtuelles Gerät mit dem Kanal, was dann noch notwendig ist weiß ich nicht mehr. Das kompilieren für einen Raspberry war mir damals einfach zu kompliziert, das hätte zu viel Bastelei bedeutet und deshalb hab ich das alles nie weiter verfolgt weil ich es auch schlicht und einfach bislang nicht gebraucht habe. Wenn du noch 1-2 Jahre warten würdest dann würde ich mich damit vielleicht nochmal beschäftigen, aber im Moment ist es mir eigentlich ziemlich egal, aber vielleicht kannst du ja damit was anfangen und rausfinden ob was fehlt und was es ist was fehlt.

#8

Ok, danke für deine Hinweise. Bezieht sich deine Aussage auf ein bestimmtes virtuelles Gerät oder allgemein die Möglichkeit?

#9

Damit das Thermostat angesteuert werden kann müssen die Daten von einem Gerät kommen, da wir keinen echten Kontakt haben wird ein virtueller erzeugt und damit verbunden. Wenn Daten gesendet werden dann müssen die natürlich so aussehen als ob sie von dem virtuellen Kontakt kommen.

#10

Der Test mit dem CC1101 muss leider warten. Der CC1101 hat ein Rastermaß von nur 2mm und da passen meine Jumperkabel nicht.

Ich wollte es dann aber mal mit meinem CUL (umgeflashter MAX!Cube) testen. Aber das von mir kompilierte MAX Modul lässt sich nicht laden. Im Error Log steht folgendes:

09/13/20 15:50:15.918 Critical: Could not open module “/var/lib/homegear/modules/mod_max.so”: /var/lib/homegear/modules/mod_max.so: undefined symbol: _ZN7BaseLib7Systems4Peer17addRoleToVariableEiRNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEmNS_13RoleDirectionEbbNS_13RoleScaleInfoE

Darin sind bisher lediglich die Änderungen von Flole noch nichts eigenes von mir.

#11
#12

Bist du dir sicher das es zueinander passende Versionen von Library und Core sind? Ich würde mal behaupten das es auch ohne meine Änderungen nicht funktioniert.

#13

Guter Tipp, wollte die lib gerade in mein Homegear im Docker einbauen und das klappt nicht. Ansonsten habe ich gerade nur eine virtuelle Maschine hier zum testen, aber das klappt das pairing nicht

#14

Danke für das Angebot, aber eigentlich möchte ich das am Ende eh mit nem CUL laufen lassen, da Homegear bei mir normalerweise nicht auf nem Raspberry läuft- Wäre jetzt nur als Zweitsystem zum testen gedacht gewesen. Da muss ich mir jetzt wohl nen zweiten CUL zum testen bauen.

1 Like
#15

Hab jetzt die passende Core Version.
Pairen von MAX Devices mit Homegear scheint weiterhin zu funktionieren. Ich habe aber aktuell noch Schwierigkeiten ein virtuelles Device mit dem physischen MAX Device zu verlinken. Habe es zunächst mit dem VirtualWindowSwitch aus der Miscallaneous Famile versucht, aber der hat keinen Sendechannel bzw. bekomme ich die Meldung “…not implemented by this Central”. Daher denke ich, dass MIscallaneous evtl. standardmäßig nicht in der Lage ist zum Pairing?

Also falls hier jemand nen allgemeinen Tipp zum Pairing von virtuellen Geräten hat wäre ich sehr dankbar. Ansonsten recherchiere ich weiter in Richtung virtuelles MAX Gerät.

#16

Virtuelle Geräte können nicht gepairt werden, das steht so auch in https://forum.homegear.eu/t/auf-windowswitchreceiver-schreiben/

#17

Dann habe ich mich vielleicht falsch ausgedrückt. Mein Verständnis/Plan war das virtuelle Gerät auf den Stellantrieb zu linken. So wie es in dem Beitrag vorgeschlagen ist:

Deine Ergänzungen der MAXCentral hatte ich so verstanden, dass diese das Linken ermöglichen sollen. Oder bin ich da falsch?
Der VirtualWindowContact wie er in Miscallaneous enthalten ist lässt sich allerdings nicht linken.
Fehlen würde bei einem erfolgreichen Link ja nur noch der Teil, welche mit dem entsprechenden Payload (Fenster offen/zu) das Funkpacket zusammenbaut. Dieser ließe sich in den von dir verlinkten FHEM Quellen lesen und adaptieren.

#18

Nein die Erweiterung legt ein (verstecktes) virtuelles Gerät an und linkt das dann. Das eigentliche Schreiben fehlt glaub ich noch (war aber als direktes schreiben gedacht, also das es ein ganz normaler schreibbarer Kanal wird). Das ist alles schon ziemlich lange her…

#19

Ah ok, danke für die Klarstellung. Geht das Schreiben dann von diversen Geräten (könnte schwierig mit den Datentypen werden)? Oder eben über Regeln/Openhab etc?
Ich sollte den Code nochmal genauer lesen glaube ich

#20

Es war hier eine Weil sehr still, da ich wenig Zeit hatte. Ich habe allerdings weiter am Code gearbeitet und bin auf weitere Fragen gestoßen. Daher habe ich den alten Issue in Github wiederbelebt. Wer Interesse am aktuellen Fortschritt hat, kann am besten dort nachschauen. https://github.com/Homegear/Homegear/issues/313