Entwicklung virtueller Raumtemperaturfühler

Deutsche Foren Software
#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

#21

Ich glaube du entwickelst da etwas in die falsche Richtung. Es ist, wenn mich jetzt nicht alles täuscht, gar nicht so kompliziert das man komplette virtuelle Geräte erstellen muss. Ein virtuelles Gerät zu pairen und dann die Pakete einfach davon zu versenden dürfte ausreichend sein, die komplette virtual device family dafür zu implementieren ist glaube ich nicht notwendig.

2 Likes
#22

Danke für den Hinweis Flole, je weniger ich machen muss desto besser.
Ich schaue mir deine Vorarbeit und den ganzen Code drum herum unter dem Gesichtspunkt nochmal an und werde das denke ich probieren.

1 Like
#23

Verstehe ich das richtig, dass du meinst ein virtuelles BC-TC-C-WM-4 als Wandthermostat bzw. BC-SC-Rd-WM-2 als Fenstersensor müsste ich gar nicht mit einer eigenen Klasse erstellen. Sondern könnte einfach einen BasicPeer nehmen, so wie in dem Code zum pairen von dir damals?
Den Code zum senden bringe ich dann wahrscheinlich irgendwo in einer der MAX Klassen unter. Ich schaue da noch weiter rein.

#24

Es tut mir echt leid, ich weiß es nicht mehr wie ich mir das genau gedacht hatte. Ich weiß nur noch das mein Code direkt beim koppeln ein pairing anlegen sollte. Auch ein command wollte ich dafür vorsehen. Die logische Schlussfolgerung ist nun eigentlich, dass die Befehle dann “transparent abgefangen” werden und von einem virtuellen Gerät aus versendet/simuliert werden. Wenn ich mehr Zeit hätte dann würde ich mir das auch nochmal anschauen und dann auch einen entsprechenden Buildserver aufsetzen, aber das ist im Moment zeitlich einfach absolut nicht drin. Im Prinzip ist im FHEM Quellcode alles drin, den wollte ich einfach nachbauen und ich weiß gar nicht mehr warum genau ich damit aufgehört hab (vielleicht steht das auch hier oder auf GitHub irgendwo).

#25

Kein Thema, ich glaube diesmal habe ich wirklich verstanden was du meinst. Ich habe mittlerweile auch verstanden, warum du Channel -1 verlinkt hast damals. Der ist für die Systemvariablen.
Kompilieren mache ich im Moment auf ner VM bei mir lokal auf dem Rechner. Zum testen reicht das denke ich aus, da ich Homegear auch nicht auf einem Raspi betreibe ist da ja recht unkompliziert und ich muss nichts cross compilen.
Ich kämpfe mich weiter durch. Ich wollte jetzt auch eigentlich zunächst den Fensterkontakt machen, weil ich dachte der wäre simpler. Allerdings verwendet FHEM als für offen und zu ‘12’ bzw. ‘10’, da muss ich noch rausfinden wo/wie aus den Strings die passenden Werte für den payload generiert werden. Aber das klappt schon noch.