Helios KWL mittels RS485 an KNX

[tuxedo]

Hab mal angefangen die finnische Doku zu übersetzen:

https://docs.google.com/document/d/1...B9ercx5NY/edit

(c) des originals liegt bei Vallox. Die Übersetzung bisher ist von mir bzw. google-translate. Wer mitmachen will ist gerne dazu eingeladen.

[derBert]

Da ich, bis auf Benji, offenbar der einzige bin den das hier interessiert, ...

Nein, auch ich sperre gerade (hab's jetzt erst gelesen) ganz aufmerksam meine Äuglein auf. Wenn Helios=Vallox, dann müsste das ja für meine Vallox 500SE auch funktionieren, oder? Da wäre ich dabei.

[tuxedo]

Hallo derBert,

die Doku der diese Entwicklung zugrunde liegt ist von Vallox und passt auch auf Helios. Für deine Vallox sollte es dann funktionieren.
Das Tool ist eigentlich auch nix neues. Nur spricht es jetzt direkt KNX und braucht keinen HS oder ähnliches der eine Webabfrage o.ä. macht.

Smarthome.py Nutzer können das Script auch direkt nutzen. Dann brauchts dieses Tool hier nicht.

Gruß
Alex

[tuxedo]

Ein Gerät weniger wäretoll gewesen, daher die Frage, ob es auf dem WG laufen würde.

Java wird sicherlich auch auf dem Wiregate laufen. Insofern sollte das nicht so das Problem sein HeliosKwlRemote auf der WG Hardware laufen zu lassen. Den einzigen Ressourcenhunder den Java hat ist ggf. RAM.
Nur hab ich mit der Wiregate-Software 0 Erfahrung und kann da mangels Hardware nix beisteuern.

[Marino]

Moin Alex,

ich möchte nur, dass Du weißt, wenn ich ein "Problem" schreibe, dass ich nur darauf hinweisen möchte, falls es noch nicht aufgefallen ist. Laufen tut ja soweit alles und ich habe ja auch keine Helios-KWL. Also bitte nicht als Gemeckere ansehen. Tust Du sicher auch nicht, ich wollte es aber nochmal sagen.

Man war ich froh, als vorhin alles das erste Mal lief. Echt toll.
Und überhaupt, danke, dass Du mir dabei hilfst, auch wenn Du nebenbei weiter daran arbeitest, wenn ich mir mit den Anfängerfragen komme



Fernbedienung:
Das mit der Fernbedienung stört mich persönlich nun gar nicht. Wenn irgendwann alles klappt, kommt die ab. Wenn ich sie nutzen möchte, kann ich sie einfach an schalten. Da sehe ich gar keinen Handlungsbeadarf, im Gegenteil. Ich finde es so gut.

Verhalten nach einschalten:
So wichtig ist es meines Erachtens nicht, da man nicht auf 8 ausmacht. Wenn ich auf 4 ausmache, weil ich Fenster offen haben möchte, dann geht er auf 4 wieder an. Zur Not setzt man sich eine Logik, dass er nach dem einschalten einen bestimmten Wert fährt. Geht auch.

Stoßlüftung:
Ich mache mich mal schlau, ob die Vallox das hat. Und ja, ich habe eine Vallox ValloPlus 270 damit laufen. Ich weiß, dass sie einen Kamintaster hat, jedenfalls gibt es in der Anschlussdose dafür beschriftete Klemmen.
Ich dachte nur, es könnte ein Fehler sein. Auch hier, wenn man es braucht, kann man das mit ner Logik anstoßen, also auch nicht so wichtig. Wollte es nur der Vollständigkeit halber erwähnt haben.

Startscript:
Hatte ich vorhin noch gefunden, keine Ahnung, welchen Build.
Mein Problem war, dass der Startbefehl nicht funktionierte, wenn ich vor den Dateinamen ein "/etc/KWL/" gepackt habe, in welchem diese und auch die config ist. Dann bekomme ich die obige Fehlermeldung, dass die config nicht gefunden wird. Daher war meine Frage, wo beides am besten hin kann, damit es problemlos klappt.

SSH:
Das habe ich auch mitbekommen. Ich hatte SSH eher wie Remotebedienung gesehen.
Direkt beim Start ist später natürlich am besten, da nach Stromausfall alles wieder an geht. Momentan zum testen reicht es, wenn der SSH-PC wieder aus kann.

Ich habe mir nun "screen" installiert, damit geht es wunderbar. Danke für den Tipp


Übersetzung:
Hattest Du meinen Post #16 gesehen? Da hatte ich auf eine englische Version im Forum verlinkt

Wiregate:
Mach Dir keinen Kopf darum. Ich habe hier noch ein Pi liegen gehabt. Den nehme ich nun. Wenn alles mal Final sein sollte, kann ich da immer noch in Ruhe gucken.



@ derBert
Die KNX-Module sind bis hin zur Beschreibung von Helios und Vallox identisch.
Und wie gesagt, meine Vallox ValloPlus 270SE läuft damit. Wir haben (Mehrfamilienhaus) auch noch eine Vallox im Keller, etwas größer, ich weiß nur gerade nicht genau, welches Modell.
Also: Bleib auf jeden Fall dran!

[tuxedo]

Bin nur kurz online, deshalb halte ichs kurz:

Hattest Du meinen Post #16 gesehen? Da hatte ich auf eine englische Version im Forum verlinkt

Die ist nicht vollständig. Die Finnische enthält mehr Details.

[tuxedo]

Moin Alex,

ich möchte nur, dass Du weißt, wenn ich ein "Problem" schreibe, dass ich nur darauf hinweisen möchte, falls es noch nicht aufgefallen ist. Laufen tut ja soweit alles und ich habe ja auch keine Helios-KWL. Also bitte nicht als Gemeckere ansehen. Tust Du sicher auch nicht, ich wollte es aber nochmal sagen.

Jo, kein Stress. Passt schon.

Stoßlüftung:
Ich mache mich mal schlau, ob die Vallox das hat. Und ja, ich habe eine Vallox ValloPlus 270 damit laufen. Ich weiß, dass sie einen Kamintaster hat, jedenfalls gibt es in der Anschlussdose dafür beschriftete Klemmen.
Ich dachte nur, es könnte ein Fehler sein. Auch hier, wenn man es braucht, kann man das mit ner Logik anstoßen, also auch nicht so wichtig. Wollte es nur der Vollständigkeit halber erwähnt haben.

Laut Vallox Schnittstellendoku geht das. Bei Helios ist die Default-Einstellung "Kamintaster". Wird wohl bei Vallox auch so sein.

Werde das in einem der nächsten Updates in der Software berücksichtigen.

Startscript:
Hatte ich vorhin noch gefunden, keine Ahnung, welchen Build.
Mein Problem war, dass der Startbefehl nicht funktionierte, wenn ich vor den Dateinamen ein "/etc/KWL/" gepackt habe, in welchem diese und auch die config ist. Dann bekomme ich die obige Fehlermeldung, dass die config nicht gefunden wird. Daher war meine Frage, wo beides am besten hin kann, damit es problemlos klappt.

Nach /etc solltest du keinerlei Software packen. In /etc liegen Config-Files des Betriebssystems und dergleichen.
Ich packe alle optionale Software nach /opt ..

In diesem Fall nach /opt/HeliosKwlRemote
Dahin entpackst du die .tar.gz oder zip File, so dass die config.properties parallel zur .jar Datei liegt.

SSH:
Das habe ich auch mitbekommen. Ich hatte SSH eher wie Remotebedienung gesehen.
Direkt beim Start ist später natürlich am besten, da nach Stromausfall alles wieder an geht. Momentan zum testen reicht es, wenn der SSH-PC wieder aus kann.

Ich habe mir nun "screen" installiert, damit geht es wunderbar. Danke für den Tipp

screen ist aber kein vernünftiger Dauerzustand. Einmal Strom weg, musst du's von Hand wieder starten. Aber bis zur fertigstellung des Start-Scripts und der Anleitung dazu passt das.

So, das war's für heute.

Gruß
Alex

[Marino]

Moin Alex,

ich packe das später dann nach /opt. Ich wusste nur nicht wohin, daher habe ich einfach ersteinmal einen Ordner erstellt.

Mit screen läuft es aber testweise, da darf das zur Not noch von Hand gestartet werden, wofür screen ersteinmal geeignet ist.

Ich muss mir erstmal ne Logik basteln, damit ein wenig Automatikbetrieb statt findet. Um 22 Uhr auf Stufe 2 fand ich immer dämlich, da man am Wochenende da noch nicht im Bett ist. Mal schauen, was ich mache, ich habe ja auch noch viele Feuchtigkeitssensoren, Fensterkontakte und VOC...


Viele Grüße
Nils

[tuxedo]

Ich muss mir erstmal ne Logik basteln, damit ein wenig Automatikbetrieb statt findet. Um 22 Uhr auf Stufe 2 fand ich immer dämlich, da man am Wochenende da noch nicht im Bett ist.

Ich hab das bei mir so gemacht:

Von 22:00 abends bis 09:00 morgens --> Nachtbetrieb. Da ist die Lüftung auf jeden Fall an.
Von 09:01 morgens bis 21:59 abends --> Präsenz-Betrieb: Die Lüftung ist nur dann an, wenn mindestens einer der PMs im Haus "Präsenz" erkennt

Das ganze habe ich auf eine GA gepackt und mit dem Standby-Feature von HeliosKwlRemote verbunden.

Funktioniert bis jetzt prima. Nur fehlt eben noch die "bedarfsgerechte Lüftung". Ich schätze, wenn ich den VOC mit eingebunden habe, dass ich die Standby-Regelung gar nicht brauche. So wie es scheint gibt's dank "gesunder Bauweise" bei uns sehr wenig Bausubstanzbedingte Emmisionen, so dass nach dem morgendlichen Duschen und "automatisiertem Stoßlüften durch eine VOC-Regelung" (die es noch zu entwicklen gilt), der VOC-Wert tagspber bei Abwesenheit weitgehend im unteren Bereich bleibt. Bin da aber noch am analysieren.

Werde wohl HeliosKwlRemote dahingehend erweitern, dass man per GA einen VOC-Wert hinein füttern kann, und die Software dann Anhand einer veränderbaren Kennlinie die Lüftung selbst regelt.
Meine Helios-Anlage sieht ja auch den Anschluss eines Co2 Fühlers vor. Der Default-Schwellwert ist da bei 800ppm (glaub ich). Aber ich fand den Fühler eingangs zu teuer und "nicht smart genug", weshalb ich das bei der Hausverkabelung nicht berücksichtigt habe und das eher mit KNX erschlagen wollte.

Gruß
Alex

[Marino]

Moin Alex,
ich teste gerade und stoße hier und da auf merkwürdige Erscheinungen (siehe Edit).



Delay:
Ich versuche gerade, die KWL auf Standby zu schalten, wenn längere Zeit ein Fenster offen ist. Klappte nicht. Nun habe ich gemerkt, dass ein Delay drin ist von 50min, was ich ja beim Testen gerade "nutze". Wofür ist dieses Delay und warum so eine große Zeitangabe? Testweise habe ich mal 60000ms eingestellt.
So klappt es erstmal mit manuell in ETS schalten, auch wenn die supereinfache Logik das noch nicht so gerne möchte... grrr

Wo ist der Unterschied bei Standby zwischen "kein Idle" und "Lüftung aus"?

VOC:
Die VOC's muss ich wohl mit Logik später hinzufügen, da ich 4 habe und 5 Feuchtigkeitssensoren. Da ich eine zentrale Lüftung habe, reicht eine Wertüberschreitung alleine nicht aus. VOC direkt lesen würde für mich einen VOC im Abluftkanal bedeuten.


EDIT:
Kein Wunder, dass die Logik nicht klappt.
Logik sagt: "EIN"
ETS liest auf dem Gruppenmonitor, dass die Quelladresse 1.2.61 (Raspberry Pi für KWL) den Befehl EIN schreibt auf die GA vom Standby
Das Tool auf dem Raspberry Pi registriert davon aber komischerweise nichts


Anderes Beispiel:

• Ich schalte über über HS auf dem Tablet Powerstate auf AUS
• ETS liest auf dem Gruppenmonitor, dass der Rasberry Pi den Befehl AUS schreibt
• Das Tool auf dem Raspberry Pi sagt nichts
• Erneutes auslesen der GA mit Gruppenmonitor gibt "AUS" und ca. 100ms später "EIN"

Passieren tut leider nichts.
Schreibe ich per ETS im Gruppenmonitor, reagiert das Tool, sowie die KWL auch.
Es sollte doch eigentlich egal sein, wer der GA den Wert 1 oder 0 verpasst.


Viele Grüße
Nils

[tuxedo]

Moin Alex,
ich teste gerade und stoße hier und da auf merkwürdige Erscheinungen (siehe Edit).



Delay:
Ich versuche gerade, die KWL auf Standby zu schalten, wenn längere Zeit ein Fenster offen ist. Klappte nicht. Nun habe ich gemerkt, dass ein Delay drin ist von 50min, was ich ja beim Testen gerade "nutze". Wofür ist dieses Delay und warum so eine große Zeitangabe? Testweise habe ich mal 60000ms eingestellt.
So klappt es erstmal mit manuell in ETS schalten, auch wenn die supereinfache Logik das noch nicht so gerne möchte... grrr

Die 50min waren ein versehen. Sollten 5min sein. Hab ich vor ner Stunde bei mir auch feststellen müssen ;-)

Die Zeit die man hier angibt hat folgenden Grund:

Wenn man kein Delay hat, würde die Anlage bei sich wechselndem StandBy-Status ggf. ständig ein- und wieder ausschalten bzw. ständig den Fanspeed ändern.
Um das zeitlich etwas zu verbessern, gibt es ein Delay:

Eine Änderung des StandBy-Status hat nun X Zeit bevor sie sich auswirkt. Kommt in der Zeit nochmal eine Änderung, so wird einfach der Status der Änderung gekippt, das Delay läuft aber weiterhin ab.

So verhindert man das schnelle Toggeln des Status und das damit verbundene "stressen" der Hardware. Ich weiß nämlich nicht wie lange die Anlage leben würde wenn wegen einer Fehlkonfiguration die Lüftungsanlage im 1sek Interval ein und wieder aus geht, und das erst mit "beißendem Rauch" bemerkt wird wenn der erste am Abend wieder heim kommt.

Wo ist der Unterschied bei Standby zwischen "kein Idle" und "Lüftung aus"?

-1 = StandBy Funktion abgeschaltet. Das Gerät geht nie in den StandBy und ignoriert die Werte an der entsprechenden GA.
0 = Gerät geht in StandBy mit "Anlage abschalten"
1..8 = Gerät geht mit dieser Fanspeed in den StandBy

VOC:
Die VOC's muss ich wohl mit Logik später hinzufügen, da ich 4 habe und 5 Feuchtigkeitssensoren. Da ich eine zentrale Lüftung habe, reicht eine Wertüberschreitung alleine nicht aus. VOC direkt lesen würde für mich einen VOC im Abluftkanal bedeuten.

Wenn du die VOC dezentral hast, dann würde ich hier den MAX-Wert aus allen Sensoren ermitteln in diesen in die Software füttern. Diese Lüftet dann entsprechend einer eingestellten Kurve und eines eingestellten Schwellwertes. Alles andere macht ja keinen Sinn.
Bei den Feuchtesensoren das gleiche in grün. Evtl. auch den Durchschnitt aus allen. Hier müsste ich in der Implementierung halt schauen dass das neben der VOC-Regelung harmoniert.

EDIT:
Kein Wunder, dass die Logik nicht klappt.
Logik sagt: "EIN"
ETS liest auf dem Gruppenmonitor, dass die Quelladresse 1.2.61 (Raspberry Pi für KWL) den Befehl EIN schreibt auf die GA vom Standby
Das Tool auf dem Raspberry Pi registriert davon aber komischerweise nichts

Ich fasse zusammen:

1.2.61 ist dein HeliosKwlRemote
Und diese schreibt auf die StandBy GA eine 1, und du wunderst dich dass sie nicht darauf reagiert?

1) Wenn HeliosKwlRemote auf die StandBy GA eine 1 schickt, dann als ANTWORT und nicht als SCHREIBEN
2) HeliosKwlRemote reagiert auf die GAs nur, wenn es SCHREIBEN und nicht ANTWORT ist, sonst beisst sich die Katze ja selbst in dern Schwanz.

Irgendwas stimmt hier noch nicht....

Anderes Beispiel:

• Ich schalte über über HS auf dem Tablet Powerstate auf AUS
• ETS liest auf dem Gruppenmonitor, dass der Rasberry Pi den Befehl AUS schreibt
• Das Tool auf dem Raspberry Pi sagt nichts
• Erneutes auslesen der GA mit Gruppenmonitor gibt "AUS" und ca. 100ms später "EIN"

Passieren tut leider nichts.
Schreibe ich per ETS im Gruppenmonitor, reagiert das Tool, sowie die KWL auch.
Es sollte doch eigentlich egal sein, wer der GA den Wert 1 oder 0 verpasst.

Erklär mir mal wie es sein kann, dass dein Tablet den Power-State schreibt, im Gruppenmonitor aber zu sehen ist dass der Raspi (HeliosKwlRemote) diesen Befehl schreibt???

Hast du vllt. ein PA-Addresskonflikt?

Gruß
Alex

[tuxedo]

Mal was anderes zum Thema StandBy:

Mein VOC hängt jetzt seit 2 Tagen provisorisch im Wohnzimmer und ich logge die Werte mit.

Wenn ich die Anlage auf Stufe 4 einfach durchlaufen lasse, dann habe ich VOC Werte um 600-700 wenn nicht gerade gekocht oder geduscht wird.

Habe vorhin dann den StandBy auf "Anlage abschalten" eingestellt. D.h. -> Keiner zuhause -> Anlage AUS.

Nach ca. 2h ist der Wert von ca. 620 auf ca. 900 angestiegen.

"komplett aus" ist also wohl keine so gute Idee.

Aktuell probiere ich den standby_speed = 1 aus und schaue wie sich der Wert da verhält.

"Cool" wäre eine Logik die den optimalen standby_speed ermittelt, sich also selbst "einstellt".

[Marino]

Eben beim anmelden mit "screen -r" waren ein paar Fehler zu sehen:
Keine Ahnung warum, vorher ging es ja. Ich habe nur die Daten für incoming_temp genommen, der Rest dazwischen ist ja uninteressant. Ich habe das Tool beendet und wieder gestartet und er hat es klaglos wieder

[SIZE=10px]...[/SIZE]  [FONT=Menlo][SIZE=11px][SIZE=10px]2015-04-30 13:14:55.793 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: 'incoming_temp' changed value from 23 to 22. Sending update to 7/0/53
...[/SIZE][/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px][SIZE=10px]2015-04-30 13:33:25.830 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: 'incoming_temp' changed value from 22 to 23. Sending update to 7/0/53
...[/SIZE][/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px][SIZE=10px]de.root1.helios.TelegramException: Error while reading 'incoming_temp'. Max attempts 10 reached.[/SIZE][/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px][SIZE=10px]        at de.root1.helios.Helios.readValue(Helios.java:599)[/SIZE][/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px][SIZE=10px]        at de.root1.helios.HeliosVariableCache.hasChanged(HeliosVariableCache.java:51)[/SIZE][/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px][SIZE=12px][SIZE=10px]        at de.root1.helios.HeliosKwlRemote$1.run(HeliosKwlRemote.java:173)
...
2015-04-30 13:53:31.219 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: 'incoming_temp' changed value from 0 to 23. Sending update to 7/0/53[/SIZE][/SIZE][/SIZE][/FONT]
 [SIZE=12px][/SIZE]

Während ich unten gerade schreibe, bekomme ich solche Fehler nicht nur zudem auch für boost_remaining... Beim Programmstart hat er damit noch kein Problem.




Nun aber zum vorherigen Problem:

• Ich habe einen neuen Dummy erstellt und extra die 1.2.61 genommen, da 1.2.60 das Wiregate ist und alles andere davon weit entfernt liegt. PA geprüft und kein Gerät gefunden, kann ja auch nicht. PA 1.2-Bereich gescannt, nichts doppelt.
• Standby ist in der config auf 0, also sollte nichts ignoriert werden
• Ich ging davon aus, dass das Tool schreibt, da "Typ: schreiben" mit Quelle des Pi's im Gruppenmonitor auftaucht
• Schicke ich in ETS den Wert "1" auf die GA vom Standby, geht die KWL in Standby
• Schickt das Tablet über den HS eine "1" auf die GA vom Standby, kommt es in ETS an, wird aber nicht umgesetzt (siehe die kleinen beiden Bilder unten)

Wenn ich eine Steckdose mit dem Tablet schalte, wird auch als Quelle der Rasperry Pi angegeben.
Auch wenn die Dummy vom HS angegeben ist und auch, wenn der GA nur vom HS ein KO zugeordnet ist und nicht vom Raspberry, behauptet er, der Raspberry Pi wäre die Quelle. Genauso, wie die beiden kleinen Bilder unten.

Startet der Raspberry Pi neu und ich sende auf über den HS eine "1" auf eine Steckdosen, behauptet der Gruppenmonitor, die Quelle wäre der Raspberry Pi. Die GA hat nur den Schaltaktor, Taster und Dummy KO vom HS eingetragen UND der Aktor schaltet, im Gegensatz zum anderen Befehl.


Start des Tools gibt mir:

 [FONT=Menlo][SIZE=11px]2015-04-30 13:57:07.178 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Connecting to Helios KWL on 192.168.0.64:4000[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:07.343 INFO [main] de.root1.helios.Helios.connect: Connecting...[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:07.514 INFO [main] de.root1.helios.Helios.connect: Connected![/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:08.740 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Initialize cache variables with 1000ms cache-keep-time[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:08.771 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Starting SendOnUpdate thread[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:08.785 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: Waiting for KNX individual address[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:08.784 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'standby' on 7/0/40[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:08.817 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'clean_filter' on 7/0/59[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:08.825 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'fanspeed' on 7/0/42[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:08.833 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'fan_in_percent' on 7/0/45[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:08.842 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'incoming_temp' on 7/0/53[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:08.850 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'device_error' on 7/0/60[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:08.858 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'power_state' on 7/0/41[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:08.867 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'boost_status' on 7/0/57[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:08.875 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'fan_out_percent' on 7/0/46[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:08.884 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'boost_remaining' on 7/0/58[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:08.892 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'min_fanspeed' on 7/0/43[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:08.900 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'outside_temp' on 7/0/51[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:08.908 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Setting default: fanspeed -> 4[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:08.956 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'inside_temp' on 7/0/54[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:08.965 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'max_fanspeed' on 7/0/44[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:08.973 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'bypass_temp' on 7/0/50[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:08.982 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'bypass' on 7/0/49[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:08.990 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'exhaust_temp' on 7/0/52[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:09.000 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Setting default: clean_filter -> 4[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:09.019 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Register listener for 'boost_on' on 7/0/56[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:09.027 INFO [main] de.root1.helios.HeliosKwlRemote.<init>: Setting individual address to 1.2.61[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:09.800 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: running![/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:09.957 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: 'device_error' changed value from 0 to 0. Sending update to 7/0/60[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:10.340 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: 'fanspeed' changed value from 0 to 4. Sending update to 7/0/42[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:10.484 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: 'max_fanspeed' changed value from 0 to 8. Sending update to 7/0/44[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:10.629 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: 'clean_filter' changed value from 0 to 4. Sending update to 7/0/59[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:10.827 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: 'power_state' changed value from 0 to 1. Sending update to 7/0/41[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:10.968 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: 'incoming_temp' changed value from 0 to 23. Sending update to 7/0/53[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:11.135 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: 'boost_status' changed value from 0 to 0. Sending update to 7/0/57[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:11.277 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: 'boost_on' changed value from 0 to 0. Sending update to 7/0/56[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:11.557 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: 'outside_temp' changed value from 0 to 12. Sending update to 7/0/51[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:11.700 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: 'exhaust_temp' changed value from 0 to 16. Sending update to 7/0/52[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:11.846 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: 'min_fanspeed' changed value from 0 to 1. Sending update to 7/0/43[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:11.988 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: 'bypass_temp' changed value from 0 to 12. Sending update to 7/0/50[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:12.131 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: 'boost_remaining' changed value from 0 to 0. Sending update to 7/0/58[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:12.274 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: 'fan_out_percent' changed value from 0 to 100. Sending update to 7/0/46[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:12.418 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: 'fan_in_percent' changed value from 0 to 100. Sending update to 7/0/45[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:12.561 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: 'bypass' changed value from 0 to 0. Sending update to 7/0/49[/SIZE][/FONT]
  [FONT=Menlo][SIZE=11px]2015-04-30 13:57:12.704 INFO [SendOnUpdate] de.root1.helios.HeliosKwlRemote$1.run: 'inside_temp' changed value from 0 to 23. Sending update to 7/0/54[/SIZE][/FONT]

In ETS zeigt er das an, wie im Anhang (Ich kann hier gerade komischerweise nichts hochladen:
http://picload.org/view/ididrgr/startdestools.png.html


Soweit, so gut.

Gebe ich den Befehl für Powerstate oder Standby, liest der Gruppenmonitor:
http://www.pic-upload.de/view-268790...20.41.png.html
http://www.pic-upload.de/view-268790...20.18.png.html

Dort ist als Quelle der Pi angegeben.
Ausgabe vom Tool gibt es nichts, da passiert nichts.

Ich steige da gerade nicht hinter, warum der ETS Gruppenmonitor immer behauptet, alles käme vom Raspberry, auch wenn dieser gerade neu startet und mit dem Schalten einer Steckdose nichts zu tun hat.
Ich muss leider auch erstmal wieder raus, noch etwas arbeiten und kann erst später weiter nach dem Fehler suchen.

Viele Grüße
Nils

[tuxedo]

Eben beim anmelden mit "screen -r" waren ein paar Fehler zu sehen:
Keine Ahnung warum, vorher ging es ja. Ich habe nur die Daten für incoming_temp genommen, der Rest dazwischen ist ja uninteressant. Ich habe das Tool beendet und wieder gestartet und er hat es klaglos wieder

[FONT=Menlo][SIZE=11px][SIZE=10px]de.root1.helios.TelegramException: Error while reading 'incoming_temp'. Max attempts 10 reached.[/SIZE][/SIZE][/FONT]

Das kann vorkommen. Sollte nicht, aber kann. Erklärung:

Das RS485 Protokoll sieht es vor READ-Anfragen nach einer gewissen "Stille" auf dem Bus einmal auf den Bus zu schreiben und dann auf die Antwort zu warten. Ggf. kollidiert aber die eigene Anfrage mit anderen Nachrichten auf dem Bus. Einen mechanismus der Kollisionen 100% vermeidet gibt es nicht.
Deshalb wird bis zu 10x versucht die READ-Anfrage abzusetzen und auf die Antwort zu warten.
Schlagen 10 Versuche fehlt, gibt er für diese READ-Anfrage auf.

Die Frage ist nun: Kommt dieses "Max attempts 10 reached." ständig und bei allem, oder nur hier und da vereinzelt?

Wenn es zu häufig auftritt, müssen wir ggf. mal die Retry-Zeiten anpassen/konfigurierbar machen.
Kommt es nur hin und wieder kann man's ignorieren.

Dort ist als Quelle der Pi angegeben.
Ausgabe vom Tool gibt es nichts, da passiert nichts.

Ich steige da gerade nicht hinter, warum der ETS Gruppenmonitor immer behauptet, alles käme vom Raspberry, auch wenn dieser gerade neu startet und mit dem Schalten einer Steckdose nichts zu tun hat.

Echt seltsam. Was zeigt denn die ETS wenn du StandBy oder Power-State triggerst (mit dem Table?) und der Raspi gar nicht am Netzwerk hängt (kabel abgezogen, WLAN Stick abgesteckt) oder Stromlos ist?

Wenn da immer noch die Raspi Addresse auftaucht, dann hat tatsächlich noch ein zweites Gerät die selbe PA wie der Raspi.

Du könntest auch Testweise die Raspi PA auf 1.2.65 setzen (sofern die frei ist) und schauen ob noch immer die 1.2.61 benutzt wird wenn du StandBy schaltest.

Solange das KNX Telegram als Absender die Adresse des Pi hat, wird die Software auf dem Pi das Telegram ignorieren (weil es ja von ihm selbst kommt).

[Marino]

Ich habe nun die 1.2.65 genommen. Für den Dummy und in der config eingetragen.
Ab und an kommt ein und das selbe nun von 1.2.61 und 1.2.65 direkt hintereinander.

Ich weiß nicht, wo diese 61 herkommt. Eben konnte ich mit "standby_speed = 0" die Anlage ausschalten und danach mit "1" auf Powerstate wieder an. Wenn ich das richtig sehe, sollte man wohl eher "standby_speed = 1" verwenden, da man die Anlage alternativ ja auch abschalten kann und nicht verwirrt ist, warum sie mit "0" auf GA vom standby nicht an geht.

Nun bin ich auf der Suche, warum ich einige Befehle doppelt von 1.2.61 und 1.2.65 bekomme, da die 61 ja nicht mehr existiert.
Aus welchem Grund auch immer scheint der Wechsel ja geklappt zu haben, obwohl es nie eine 1.2.61 in dieser Anlage zuvor gab.