SID bestimmen

[tobox]

Wie kann ich eine Seite (z.B. http://ccu3/tools/devconfig.cgi?cmd=sho ... hCBhvsXDav@) automatisch per Script (wget, curl o.ä.) abholen, um die Werte zu analysieren oder zu loggen? Manuell ist das relativ einfach, wenn ich mich im Browser einlogge und die sid aus der URL kopiere, aber wie kann ich eine SID auf der Kommandozeile erstellen, sprich, wie kann ich mich mit wget auf der CCU einloggen?

Danke schonmal im Voraus, ich vermute, das Problem hatten schon mehrere - aber eine Lösung habe ich trotz längerer Suche nicht gefunden...

[Xel66]

Alle diese Daten, die dort dargestellt werden, sind als Datenpunkte auf der CCU vorhanden und können auch durch diese ohne jeglichen Umweg über ein Webinterface z.B. per Script ausgelesen werden. Dein Vorgehen ist unnötig kompliziert. Und ich glaube nicht, dass dieses Problem schon mehrere hatten, weil man selten so kompliziert denkt. Und die dort dargestellten Werte sind sowieso Hausnummern.

Gruß Xel66

[tobox]

Sorry für die späte Antwort, ich habe irgendwie keine Benachrichtigungs-Email bekommen...

Also es ist so, ich kann gewisse RSSI_DEVICE und RSSI_PEER Werte in FHEM über die normale CCU3-Anbindung auslesen, aber ich bekomme nur dieselben Werte die auch in der CCU3-GUI angezeigt werden. Wenn man ein HM-CFG-LAN als zusätzliches Gateway benutzt, bekommt man aber überall nur zufällig irgendwelche Werte angezeigt. Die devconfig.cgi ist meiner Meinung nach die _einzige_ Stelle, an der alles korrekt dargestellt wird. Man hat dort für jedes Homematic-Gerät die RSSI-Werte für jede Antenne separat angezeigt.

Hat noch jemand eine Idee?

[Xel66]

...bekommt man aber überall nur zufällig irgendwelche Werte angezeigt.

Das "überall" ist aber immer nur der Inhalt des gerätegebundenen Datenpunktes. Wo es in der WebUI dargestellt wird, ist schnurzegal. Es ist der gleiche Datenpunkt. Also kann man sich auch gleich den Datenpunkt anzeigen, zusenden, vorlesen oder was auch immer lassen.

Nur weil diese Aufbereitung es auf einer gemeinsamen Seite anzeigen kann (weil es eben diese Datenpunkte ausliest), ist noch lange nicht gesagt, dass man eine solche Seite durch den Webserver zusammenstellen, aufbereiten, auslesen, parsen muss, um nachher doch wieder den gleichen Inhalt zu erhalten, der auch mit der direkten Abfrage der Datenpunkte ohne den aufwändigen Schnichschnack zu erhalten wäre. Dein Vorhaben ist vergleichbar, als wenn Du Dir eine Visu baust, um z.B. die Daten Deiner Solaranlage über ein Tablet anzeigen zu lassen, und für die Verwendung als Push oder Datenquelle für die weitere Verarbeitung, nicht die Datenquelle ausliest, sondern die auf Deinem Tablet dargestellte Seite. Komplizierter könnte man es nur noch machen, wenn Du die Daten Deiner CCU über eine im Internet gehostete Seite einliest.

Hat noch jemand eine Idee?

Vermutlich werden viele Anwender mir zustimmen, dass es zielführender ist, die Datenquelle direkt über dokumentierte Befehle auszulesen als solch eine von-hinten-durch-die-Brust-ins-Auge-Lösung zusammenzuklöppeln. Zumal die Datenpunkte problemlos mit Bordmitteln auszulesen sind. Man muss sich nur einmalig die Mühe machen, diese zusammenzustellen.

Gruß Xel66

[tobox]

Xel66,

vielen Dank für Deine Geduld, aber ich komme nicht weiter. Ich weiß was Du meinst, und habe das damals auch schon mal ausprobiert. Wenn ich mir alle Datenpunkte eines Sensors anzeige, bekomme ich in etwas sowas:

Code: Alles auswählen

string aktor = "MEQ1658832";
! =============================================================================
string index;
string datenpunkte = dom.GetObject(ID_DATAPOINTS).EnumUsedNames();
foreach (index, datenpunkte) 
{
var sserial = (index.StrValueByIndex(":",0).StrValueByIndex(".",1));
if (sserial == aktor) 
{
WriteLine(index #": " # dom.GetObject(index).Value());
  
}
}
 

Ich bekomme immer nur einen RSSI-Wert statt den Werten für CCU3 und Gateway separat. Wo muss ich denn suchen, um die richtigen Datenpunkte zu finden?

Code: Alles auswählen

BidCos-RF.MEQ1658832:0.AES_KEY: 0
BidCos-RF.MEQ1658832:0.CONFIG_PENDING: false
BidCos-RF.MEQ1658832:0.DEVICE_IN_BOOTLOADER: false
BidCos-RF.MEQ1658832:0.LOWBAT: false
BidCos-RF.MEQ1658832:0.RSSI_DEVICE: 1
BidCos-RF.MEQ1658832:0.RSSI_PEER: 196
BidCos-RF.MEQ1658832:0.STICKY_UNREACH: false
BidCos-RF.MEQ1658832:0.UNREACH: false
BidCos-RF.MEQ1658832:0.UPDATE_PENDING: false
BidCos-RF.MEQ1658832:1.ERROR: 0
BidCos-RF.MEQ1658832:1.LOWBAT: false
BidCos-RF.MEQ1658832:1.STATE: false

Das hier sind die Werte laut DEVCONFIG, die mich eigentlich interessieren:

Screenshot_20210331_071839.png (13.28 KiB) 662 mal betrachtet

[Xel66]

Die Datenpunkte hast Du ja schon mal (BidCos-RF.MEQ1658832:0.RSSI_DEVICE und BidCos-RF.MEQ1658832:0.RSSI_PEER). Diese hatte ich auch im Hinterkopf. Nur scheinen sie nicht mit sinnvollem Inhalt gefüllt zu werden, denn wenn man sie sich anschaut, tragen sie einen Timestamp vom letzten Systemstart. Laut tcl-Script unter /www/tools/devconfig.cgi (das Script, welches Dir die RSSI-Seite zusammenbaut) werden auch diese Datenpunkte ausgelesen (catch { set rssi_device [xmlrpc $url getValue "$dev_descr(ADDRESS):0" "RSSI_DEVICE"] } catch { set rssi_peer [xmlrpc $url getValue "$dev_descr(ADDRESS):0" "RSSI_PEER"] }. Muss man mal das Script tiefer analysieren, woher es dann die aktuellen Daten bezieht. Aus den angegebenen Datenpunkten eher nicht. Zumindest scheinen sie für das tcl-Script erreichbar. Dann müssten sie es auch für ein HM-Script sein.

Gruß Xel66

[Baxxy]

War da nicht mal was mit "256 abziehen" von den Datenpunkt-Werten um auf die negative db Anzeige zu kommen?

[tobox]

War da nicht mal was mit "256 abziehen" von den Datenpunkt-Werten um auf die negative db Anzeige zu kommen?

Sowas hatte ich auch im Hinterkopf, würde im angegeben Beispiel ja auch passen: 196 - 256 = -60, Angezeigt -59/-64. Wobei mein eigentliches Problem ist, dass ich nur einen Wert bekomme, und zwar meistens den falschen.

[MichaelN]

Ich tracke diese Datenpunkte in CCU-Historian. Die werden also normalerweise aktualisiert. PEER allerdings sehr selten.

[Xel66]

Ja, solche Taschenspielertricks (-256dBm) habe ich auch schon vermutet. Bei der Darstellung der letzten bekannten Kommunikation wenden die ja ähnliches an (-128dBm). Das erklärt aber immer noch nicht, warum die Timestamps dann nicht aktualisiert werden (zumindest bei denen, die ich mir auf meinem System angeschaut habe). Müsste man sich noch mal näher anschauen.

Gurß Xel66