DutyCycle Monitoring auf der x86 Implementierung

neokalis · Beitrag von **neokalis** » 22.01.2019, 17:11

Hallo Mitstreiter,

ich hatte wieder etwas Zeit und habe mich mal mit dem DutyCycle Monitoring auf der x86 Implementierung beschäftigt, bin aber leider nicht zum Ziel gekommen. Evtl. habt Ihr ja mehr Erkenntnisse, bzw. könnt noch mal in Details schauen.

Soweit ich verstanden habe ist Quickmic mit dieser Implementierung nun ziemlich nahe an Raspberrymatic gerutscht. Hier sollen nach meinem Wissen ca. 3 Minuten nach Systemstart Variablen für den DC automatisch angelegt und befüllt werden. Dies scheint aber auf der x86 Implementierung nicht so zu sein. Wie kann ich das ggf. händisch nachziehen?

Zweiter Versuch waren dann die Skripte aus dem Thread von Alchy (viewtopic.php?f=31&t=35097&hilit=duty+cycle#p335489). Auch diese haben leider auf Anhieb keinen sinnvollen Wert ausgegeben. Ich habe es dann versucht zu zerlegen und auf der Console mal abgesetzt:

Code: Alles auswählen

echo 'load tclrpc.so; puts [xmlrpc http://127.0.0.1:32001/ listBidcosInterfaces ]'|tclsh |grep -o 'DUTY_CYCLE.[0-9]*.'

Das Ergebnis war eindeutig - selbes für Port 2001:

Code: Alles auswählen

Transport error on xmlrpc call listBidcosInterfaces to http://127.0.0.1:32001/: Error in XmlRpcClient::writeRequest: write error (error 111).

Ein netstat verrät mir auch, dass weder auf 32001 noch auf 2001 ein Listener läuft.

Code: Alles auswählen

root@ccu3:~# netstat -tnlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0                    0.0.0.0:1999            0.0.0.0:*               LISTEN      743/ReGaHss
tcp        0      0                    0.0.0.0:80              0.0.0.0:*               LISTEN      445/lighttpd
tcp        0      0                     0.0.0.0:8181            0.0.0.0:*               LISTEN      743/ReGaHss
tcp        0      0                    0.0.0.0:22              0.0.0.0:*               LISTEN      441/sshd
tcp        0      0                    0.0.0.0:443             0.0.0.0:*               LISTEN      445/lighttpd
tcp        0      0                    0.0.0.0:8700            0.0.0.0:*               LISTEN      491/cuxd
tcp        0      0                    0.0.0.0:8701            0.0.0.0:*               LISTEN      491/cuxd
tcp6       0      0                   :::9292                 :::*                    LISTEN      501/java
tcp6       0      0                   :::22                   :::*                    LISTEN      441/sshd
tcp6       0      0                   :::2010                 :::*                    LISTEN      501/java

Kann ich den XMLRPC irgendwie aktivieren oder zugänglich machen?

Unabhängig vom DutyCycle dann noch ein weiterer "Feature Request": Sowohl die CCU als auch Raspberrymatic bieten sog. virtuelle Kanäle an. Diese kann man wohl an verschiedenen Stellen einblenden, wenn man die virtuellen Kanäle öffnet, bzw. unter "Geräte" die CCU anklickt und den Button für virtuelle Kanäle wählt. Da die CCU in der vorliegenden Implementierung nicht unter "Geräte" auftaucht, gibt es die virt. Kanäle leider nicht; auch nicht unter "Direkte Verknüpfungen". Finde es hilfreich, wenn es diese auch in die Implementierung schaffen. Oder habe ich was übersehen?

Zu meinem Setup: x86-CCU auf Debian, Version 3.41.11 mit HmIP-RFUSB-TK

Zu guter Letzt: @Quickmic - Eine wirklich coole Implementierung! Magst du Dir dafür noch bei Gelegenheit einen fancy "Produktnamen" überlegen? Das macht es einfacher eigenständige Threads hier zu eröffnen und den Bezug zu Deiner Implementierung herbeizuführen. So muss man nicht den Installations-Thread fluten.

Danke vorab für alle Rückmeldungen
neokalis

quickmic · Beitrag von **quickmic** » 23.01.2019, 10:35

echo 'load tclrpc.so; puts [xmlrpc http://127.0.0.1:32001/ listBidcosInterfaces ]'|tclsh |grep -o 'DUTY_CYCLE.[0-9]*.

Ich habe zwar keine Erfahrung damit, aber der Port ist sicher im falle meiner Implementierung. Da muss Port 2001 rein.

Was mich bei deinem netstat wundert. Du hast den rfd Dienst nicht drin, der hat naemlich die 2001.
Hast du einen Bidcos GW oder Stick oder irgendwas dran an der CCU? Sonnst laeuft der Dienst nicht.

Code: Alles auswählen

root@homecontrol:~# netstat -tnlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:5544            0.0.0.0:*               LISTEN      520/hm-Homematic-Ev
tcp        0      0 0.0.0.0:1999            0.0.0.0:*               LISTEN      317/ReGaHss
tcp        0      0 0.0.0.0:2000            0.0.0.0:*               LISTEN      121/hs485d
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      73/lighttpd
tcp        0      0 0.0.0.0:2001            0.0.0.0:*               LISTEN      125/rfd
tcp        0      0 0.0.0.0:50002           0.0.0.0:*               LISTEN      523/hm-Commands
tcp        0      0 0.0.0.0:8181            0.0.0.0:*               LISTEN      317/ReGaHss
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      82/sshd
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      73/lighttpd
tcp6       0      0 :::9292                 :::*                    LISTEN      134/java
tcp6       0      0 :::22                   :::*                    LISTEN      82/sshd
tcp6       0      0 :::2010                 :::*                    LISTEN      134/java

Unabhängig vom DutyCycle dann noch ein weiterer "Feature Request": Sowohl die CCU als auch Raspberrymatic bieten sog. virtuelle Kanäle an.

Das ist bereits der Fall, aber selbe Frage. Laeuft der rfd Dienst? Sonnst wirst vermutlich keine Virtuellen Kanaele bekommen.
Falls das dann noch immer nicht klappt, schau ich nochmal rein.

neokalis · Beitrag von **neokalis** » 23.01.2019, 17:25

Hi!

Was mich bei deinem netstat wundert. Du hast den rfd Dienst nicht drin, der hat naemlich die 2001.
Hast du einen Bidcos GW oder Stick oder irgendwas dran an der CCU? Sonnst laeuft der Dienst nicht.

Nichts der Gleichen. Will ja auch eigentlich nur HmIP nutzen und hab BidCos erst gar nicht installiert... Nun habe ich BidCos mal schnell über den Installer nachgezogen, aber logischerweise startet der ohne Gerät nicht. Irgendeine Chance trotzdem an den RFD / XMLRPC / virt. Kanäle zu kommen?

Nun der Namen ist im Moment "x86-CCU". Ich kann mir bei Bedarf noch was ueberlegen falls das verwirrend ist.
Ich bin aber auch dafuer, dass seperate Threads fuer unterschiedliche Probleme erstellt werden.

Alles klar - zukünftig separate Threads mit dieser Bezeichnung als Tag. Da es schon div. Ansätze für x86 gab, dachte ich der Name ist evtl. nicht eindeutig genug. Aber am Ende muss die Lösung ja nur marktbeherrschend genug sein, um sich den Namen zu sichern!

Danke für die Hilfe!

quickmic · Beitrag von **quickmic** » 23.01.2019, 18:12

Ok, wenn du kein bidcos verwendest, kann der command nicht funktionieren. Auch wenn du auf 2001 aenderst, denn das ist der Bidcos port.

Code: Alles auswählen

echo 'load tclrpc.so; puts [xmlrpc http://127.0.0.1:32001/ listBidcosInterfaces ]'|tclsh |grep -o 'DUTY_CYCLE.[0-9]*.

Bei mir wird fuer HMIP auch kein Duty-Cycle angezeigt. Wurde das beim Raspimatic angezeigt? Ich wuesste naemlich nicht wo.
Es gibt aber zumindest einen Parameter bei meinem HMIP-PSM.

Code: Alles auswählen

homematic|0001d8a98efe06:0|unreach|0
homematic|0001d8a98efe06:0|rssi_device|-34
homematic|0001d8a98efe06:0|duty_cycle|0
homematic|0001d8a98efe06:0|rssi_peer|-37
homematic|0001d8a98efe06:2|section_status|0
homematic|0001d8a98efe06:2|state|1
homematic|0001d8a98efe06:2|section|2
homematic|0001d8a98efe06:2|process|0
homematic|0001d8a98efe06:3|section_status|0
homematic|0001d8a98efe06:3|state|1
homematic|0001d8a98efe06:3|section|2
homematic|0001d8a98efe06:3|process|0
homematic|0001d8a98efe06:4|section_status|0
homematic|0001d8a98efe06:4|state|0
homematic|0001d8a98efe06:4|section|0
homematic|0001d8a98efe06:4|process|0
homematic|0001d8a98efe06:5|section_status|0
homematic|0001d8a98efe06:5|state|0
homematic|0001d8a98efe06:5|section|0
homematic|0001d8a98efe06:5|process|0
homematic|0001d8a98efe06:6|voltage|232.6
homematic|0001d8a98efe06:6|power_status|0
homematic|0001d8a98efe06:6|energy_counter|587.0
homematic|0001d8a98efe06:6|current_status|0
homematic|0001d8a98efe06:6|frequency|49.97
homematic|0001d8a98efe06:6|energy_counter_overflow|0
homematic|0001d8a98efe06:6|power|0.0
homematic|0001d8a98efe06:6|voltage_status|0
homematic|0001d8a98efe06:6|current|0.0
homematic|0001d8a98efe06:6|frequency_status|0

Bekanntlich fungieren die HMIP Steckdosen als Repeater, wuerde also Sinn ergeben, dass da ein Dutycycle vorhanden ist.
Beim HMIP-USB Stick habe ich noch nichts dergleichen auslesen koennen. Sollte aber auch einen geben.
Ich schau ob ich da was machen kann, oder zumindest ein Script dafuer.

Zum Thema virtuelle Kanäle muss ich testen. Bei HMIP only glaube ich mich zu erinnern, dass ich auch keine hatte.
Schau ich mir auch an, wird aber etwas dauern.

neokalis · Beitrag von **neokalis** » 24.01.2019, 17:26

Bei mir wird fuer HMIP auch kein Duty-Cycle angezeigt. Wurde das beim Raspimatic angezeigt? Ich wuesste naemlich nicht wo.

Ob das Raspberrymatic funktoniert, kann ich nicht sagen. Ich hatte nie eine Installation, sondern auf der grünen Wiese mit x86-ccu begonnen. Habe nur gelesen, dass eben dort eine Standardimplementierung für den DC existiert. Und weil mir in der Forensuche nichts anderes aufgefallen ist, bin ich davon ausgegangen, dass diese, ebenso wie die Skripte von Alchy et al, über den XMLRPC auch den DC für HmIP anzeigen.

Ich glaube aber, ich habe jetzt eine Lösung gefunden. Schlüssel war folgender Kommentar: viewtopic.php?f=31&t=35097&p=419721&hilit=HmIp#p419721

Tatsächlich Wenn man den Call auf Port 2010 macht, dann kommt auch ein Ergebnis für HmIP Only. Kannst du das mal gegeprüfen?

Code: Alles auswählen

root@ccu3:~# echo 'load tclrpc.so; puts [xmlrpc http://127.0.0.1:2010/ listBidcosInterfaces ]'|tclsh |grep -o 'DUTY_CYCLE.[0-9]*.'
DUTY_CYCLE 1

Oder einfach die URL in den Skripte von Alchy ändern und es scheint zu gehen.

Zum Thema virtuelle Kanäle muss ich testen. Bei HMIP only glaube ich mich zu erinnern, dass ich auch keine hatte.

Eilt nicht. Bei den virt. Kanälen kann man sich ggf. auch anders behelfen (CuxD, Programme)

Beitrag von **alchy** » 24.01.2019, 18:19

neokalis hat geschrieben: ↑
24.01.2019, 17:26
Tatsächlich Wenn man den Call auf Port 2010 macht, dann kommt auch ein Ergebnis für HmIP Only. Kannst du das mal gegeprüfen?

Das geht natürlich, auch wenn die Werte RF/IP nur marginal versetzt sind.
Meine Scripte sollten theoretisch überall laufen,( zu mal es erst ein Update gab.)

Alchy

neokalis · Beitrag von **neokalis** » 24.01.2019, 18:53

Meine Scripte sollten theoretisch überall laufen,( zu mal es erst ein Update gab.)

In der neuen Version bekomme ich beim "skript testen" sowohl für Variante a) als auch c) leider gar keinen Output. Noch nicht mal Fehler.

Anyway - jetzt funktionierts ja!

Beitrag von **alchy** » 24.01.2019, 19:23

Weil du kein BidCos-RF Interface hast, dann musst du eben entsprechend das IP Interface HmIP-RF eintragen.

Alchy

neokalis · Beitrag von **neokalis** » 24.01.2019, 19:47

Das ergibt irgendwie Sinn!

Sorry, hatte mir die neue Fassung nicht im Detail angesehen, weil meine Bastelei schon letzte Woche vor deren Veröffentlichung begann und ich auch kein Script-Profi bin.

Für meine Nachwelt:
In den Skripten von Alchy et al.

Code: Alles auswählen

interfaces.Get("BidCos-RF")

austauschen auf

Code: Alles auswählen

interfaces.Get("HmIP-RF")

und schon gibts brauchbare DC Werte.

Damit bleibt mir nur noch mich für alle Hilfe zu bedanken!

HomeMatic-Forum / FHZ-Forum