LBS 19001230, Pluggit Avent P310 KWL ModbusTCP

[KFlo]

BadWicky

Sorry, genau weiß ich es nicht, weil ich EDOMI mit CentOS 6 einsetze.

Lt. dieser Info...
https://knx-user-forum.de/forum/projektforen/edomi/1403580-modbusmaster-für-php-7-unter-centos7
...würde ich versuchen, in der /usr/local/edomi/main/include/php/ModbusMaster.php
die Zeile

function ModbusMaster($host, $protocol){ 

ersetzen durch

function __construct($host, $protocol){ 

Hat es geklappt?

[BadWicky]

KFlo,

super Tipp hat funktioniert, danke für deine Hilfe

[BadWicky]

KFlo, Hallo

ich habe heute ein komisches Problem seit dem ich eine Projektaktivierung gemacht habe. (ich denke dass es seitdem ist) Siehe Screenshot anbei.
Die Pluggit Anlage lässt sich soweit über die Firmeneigene App ansteuern auch in der Fritzbox ist Sie vorhanden nur nicht in edomi.
Was komisch ist das meine Ausgangsboxen nicht mehr belegt werden und eben der oben genannte Fehler, hast Du hierfür eine Erklärung?

[BadWicky]

Hallo hat keiner eine Idee??

bezüglich des vorher genannten Fehlers


Was ich jetzt schon alles gemacht habe:

Den LBS gelöscht neu aufgebaut und eingelesen = nichts gebracht
Netzwerkverkabelung geprüft = nichts gebracht
Die Dateien IecType.php /ModbusMaster.php / ModbusMasterTcp.php / ModbusMasterUdp.php / PhpType.php ersetzt durch die im LBS mitgelieferten = nichts gebracht

Was komisch ist, dass in edomi der Fehler wenn er gelöscht wurde nicht mehr kommt und die Lüftungsanlage vom LBS trotzdem keine Werte ausgibt.

[jonofe]

No route to host bedeutet, dass es keine Netzwerkverbindung gibt, Evtl. falsche IP eingegeben?
Ich würde mal versuchen vom EDOMI Server ein Ping auf das Gerät zu machen.

[BadWicky]

Hi jonofe,

weißt du was das Problem war. Ich hab bei der Pluggit intern eine dhcp Zuweisung gehabt. Jetzt habe ich eine feste IP Adresse in der Pluggit Anlage intern hinterlegt, obwohl ich die feste IP aus der fritzbox vergeben habe diese auch angezeigt wurde. Nach der Änderung funktioniert es seit gerade eben wieder. Warum dies jetzt so war kann ich leider nicht beantworten. Der Baustein läuft ja bestimmt schon seit 2 Jahren.

Gruß

[darkevil]

Hallo zusammen,

bei meiner kleinen KWL A D160 wurde der VOC Werte immer mit "0" ausgeben.

Mit folgender Änderung im LBS tut es nun.

Alt:

// A16: VOC
$recData = $modbus->readMultipleRegisters(180, 430, 2);
$values = array_chunk($recData, 4);

foreach($values as $bytes)
[MARKIEREN]$output=round(PhpType::bytes2float($bytes),2);[/MARKIEREN]
setLogicLinkAusgang($id,16,$output);
logging($id, "VOC = " .$output); usleep(1000*10);

Neu:

// A16: VOC
$recData = $modbus->readMultipleRegisters(180, 430, 2);
$values = array_chunk($recData, 4);

foreach($values as $bytes)
[MARKIEREN]$output=PhpType::bytes2signedInt($bytes);[/MARKIEREN]
setLogicLinkAusgang($id,16,$output);
logging($id, "VOC = " .$output); usleep(1000*10);

Bleibt Gesund!

[jaydee73]

Mal ne Frage in die Runde:

Einige Werte sind ja Ganzzahlwerte (z. B. A13 Filter Remaining Days). In der Logik wird mir das auch das Ergebnis als dezimale Zahl angezeigt. Das Script sagt mir, dass der Wert ein 2-Byte-Signed-Integer ist. Wenn ich dazu also eine entsprechende GA auswähle, um das Ergebnis auf den Bus zu bekommen, dann wäre für mich der adäquate DPT die 8.*. So sieht das auch Edomi vor. Im ETS-Gruppenmonitor bekomme ich das Ergebnis dann allerdings in hexadezimaler Form ausgegeben.

Wie habt ihr das gelöst? Rechnet ihr den Hex-Wert nochmal irgendwo in dezimal um? Oder biegt ihr den DPT irgendwo um? Ziel bei mir soll sein, die Werte auf der Visu vom Gira X1 anzeigen zu lassen. Die Edomi-Visu nutze ich (derzeit noch) nicht.

Danke,
Stefan

Edith: Ok, tlw. habe ich es mir selbst beantwortet: Wenn ich den A13-Wert, welcher als DPT 8 hexadezimal auf dem Bus landet, im X1 anzeigen lasse, dann zeigt die X1-Visu den Wert in Dezimal-Form an, also so wie es auch Sinn macht. Es muss also nichts umgerechnet werden.

[jaydee73]

Noch ne Frage:

Hat jemand zufällig den Luftfeuchte-Wert auf einen MDT GT2 gebracht? bkr , du vielleicht?

Lt. Script ist das ein 2 Byte Signed Integer (war in einer alten Version mal FLOAT...) und damit in Edomi DPT8. Auf dem GT2 möchte ich das als Standby-Statuswert anzeigen lassen. Interessanterweise kann ich dort aber DPT8 nicht auswählen, es gehen nur 5,7,9. Als 9er gibt es auch den Untertyp Luftfeuchte, aber dann wird mir der Ausgabewert nur /100 angezeigt (also 41 wird als 0,4 angezeigt).

Muss man da noch was konvertieren? Oder im Script doch auf Float (DPT9) gehen?

[jonofe]

Muss man da noch was konvertieren?

Ich bin nicht sicher, ob ich es richtig verstanden habe, aber warum multiplizierst du den Wert nicht einfach vor dem Senden mit 100?

[jaydee73]

Die Idee hatte ich auch. In der Ausgangsbox und auf der KNX-GA habe ich dann auch 4000 (bei 40% rLH), aber wenn ich die GA als Statuswert verknüpfe, kommt bei der Anzeige auf dem GT2 was für mich nicht logisches raus. Wenn ich manuell Werte für die GA auf den Bus schreibe, ändert sich der Anzeigewert auf dem GT2 nicht 1:1. Er zeigt mal 16% an, mal 40%, mal irgendwas anderes. Ich habe noch kein "Umrechnungsschema" ausmachen können.

Ich muss das nochmal etwas genauer erforschen. Ich vermute, dass liegt halt doch an den unterschiedlichen DPTs.

[jaydee73]

Hallo zusammen,
Hallo KFlo ,

bei mir taucht seit einigen Tagen unregelmäßig folgender Fehler im Edomi-Log auf:

Bildschirmfoto 2020-06-15 um 13.37.39.png

Kennt das jemand der Nutzer dieses Bausteins? Der LBS basiert ja (glaube ich...) auf dem Helios-Baustein. Dort (https://knx-user-forum.de/forum/proj...nd-edomi/page4) wurde in der Vergangenheit durchaus auch von diesem Fehler berichtet, allerdings lese ich aus den Beiträgen keine eindeutige Lösung raus.

Meiner Meinung nach wurde an meiner Edomi-Umgebung nichts geändert in den letzten Tagen, zumindest nicht das ich wüsste...

Das Einzige was mir einfällt, ist, dass die KWL gestern das erste Mal den Bypass aktiviert hat. Vielleicht aber auch schon die Tage vorher, das hatte ich nicht so im Blick. Kann mir aber nicht vorstellen, dass das damit zusammenhängt.

Gruß,
Stefan

Edith: Das Ganze läuft bei mir in einer Proxmox-VM. Habe gerade gesehen, dass die CPU-Auslastung dann auch immer einen Peak hat. Aber auch das wurde im Helios-Thread auch schon beobachtet.

[jaydee73]

Ich habe nochmal etwas geforscht, ob der Fehler mit dem Bypass zusammenhängen kann. Dabei bin ich noch auf was anderes gestoßen:

Ich schreibe die Ausgänge auf KNX-GAs und sehe im Gruppenmonitor für die Bypass-Ausgänge die vermeintlich korrekten Werte (bei geöffnetem Bypass):

A11 (Bypass Status als String): offen



A18 (Bypass Status als Zahl): 1



Das Debug-Log des LBS liefert mir jedoch für beide Register den Wert 255:

Bildschirmfoto 2020-06-15 um 19.13.55.png

Kannst du dazu auch noch etwas sagen, kflo?

Danke!

[KFlo]

Hallo jaydee73
, der Baustein läuft bei mir seit Jahren problemlos. Ich kann den Fehler leider auch nicht nachvollziehen, da ich EDOMI unter CentOS 6 einsetze und auch nicht in einer VM. Beim überfliegen des anderen Threads scheint es aber so, als würde der LBS evtl. zu häufig getriggert werden.

(Deine angehängten Bildschirmfotos kann ich nicht anzeigen)

Der Wert 255 bedeutet "Bypass offen". (0 = "Geschlossen", 32 = "wird geschlossen", 64 = "wird geöffnet")

[jaydee73]

Danke für die Antwort. Da der Baustein auch bei mir monatelang ohne Fehler funktioniert hat (mit CentOS 7 in einer VM), glaube ich eher nicht, dass hier das Problem liegt. Die Meldungen kommen ja auch nur sporadisch.

Ich habe allerdings immer noch den Bypass in Verdacht. Hast du denn bei deiner Pluggit das optionale Bypass-Modul verbaut? Das Öffnen des Bypass hat bei mir gestern Abend keinen Fehler verursacht, diesmal habe ich es beobachtet (und das Logging auf Debug gestellt). Mal schauen, was passiert, wenn der Bypass wieder geschlossen wird.

Ah, 255 heißt offen, ok. Ich war nur irritiert, weil der Name "BypassActualState-0/1" heißt und im KNX auch die 1 ankommt. Das da "intern" dann 255 verwendet wird, hat sich mir nicht direkt erschlossen.

Noch ne Frage: Im Helios-Thread hatte User SirSydom den LBS nochmal gegen diesen Fehler abgeändert und Benji (der LBS-Ersteller) daraufhin auch eine neue Version 0.6 rausgebracht. Auf welcher Helios-LBS-Version basiert denn der Code deines LBS? Auf der 0.5 oder schon auf der 0.6?