AVM Plugin

[psilo]

Sisamiwe hast du verify: False beim Plugin? Mich wundert etwas das "urllib3.connection.VerifiedHTTPSConnection object". Welche Version ist Requests? ich teste immer auf der neusten..

Die Box hat ein lokales Zertifikat, weshalb Du die Zertifikateverifizierung explizit deaktivieren musst, wenn du gegen 49433 gehst.. ggf auch mal gegen den HTTP Port 49000 testen.. Ich kenne es aus der Arbeit, dass Verbindungen wo nicht verifiziert werden kann, gerne mal austimen!

Achja ggf auch hilfreich: https://www.janrufmonitor.de/tr-064-aktivieren/ ("TR-064 ist auf allen AVM Geräten mit FRITZ!OS 5.5x im Auslieferungszustand aktiviert. Bei Geräten, die von Internet-Providern als OEM (z.B. UnityMedia, KabelBW, 1&1 etc.) zur Verfügung gestellt werden, ist dies ebenso der Fall.")

[Sisamiwe]

psilo

Zur Situation bzw. den Ergebnissen der Versuche:

• Der CallMonitor ist aktiviert.
• Für shNG wurde ein eigener Benutzer angelegt.
• Die Rechte sind entsprechend erteilt.

Auf meiner Produktivintanz mit Core 1.6 Master und Pluglins 1.6.1 Master habe ich foglende Einträge in der etc/plugin.yaml

fb1:[INDENT]class_name: AVM
class_path: plugins.avm
username: smarthome
password: Fortuna1
host: 192.168.2.1
port: 49443
cycle: 120
ssl: true # use https or not
verify: false # verify ssl certificate
call_monitor: 'True'
# "call_monitor_incoming_filter = ... #optional, don't set if you don't want to watch only one specific number with your call monitor"
instance: fritzbox_7560[/INDENT]
 
fb3:[INDENT]class_name: AVM
class_path: plugins.avm
username: smarthome
password: Fortuna1
host: 192.168.2.4
port: 49443
cycle: 120
ssl: true # use https or not
verify: false # verify ssl certificate
call_monitor: 'True'
# "call_monitor_incoming_filter = ... #optional, don't set if you don't want to watch only one specific number with your call monitor"
instance: fritzbox_7490[/INDENT]

Das läuft seit längerem stabil.

Auf einer Testinstanz mit Core "1.6a.da992f67.develop in /usr/local/smarthome - heads/develop" und Plugins "1.6.1.135f4ddf.develop in /usr/local/smarthome/plugins - heads/develop" habe ich folgende Varianten getestet:

A) Pluginkonfiguration über das Admin Interface auf Port 49000 uns ssl: false

fb1:[INDENT]plugin_name: avm
username: smarthome
password: Fortuna1
host: 192.168.2.4
port: 49000
cycle: '120'
ssl: false
verify: false
call_monitor: true[/INDENT]

Ergebnis: Geht! Plugin verbindet, sogar parallel mit der Produktivinstanz.

B) Pluginkonfiguration über das Admin Interface auf Port 49000 uns ssl: false

fb1:[INDENT]plugin_name: avm
username: smarthome
password: Fortuna1
host: 192.168.2.4
port: 49433
cycle: '120'
ssl: true
verify: false
call_monitor: true[/INDENT]

Ergebnis: Geht nicht.

2020-01-13 21:12:21 ERROR plugins.avm Exception when sending POST request: HTTPSConnectionPool(host='192.168.2.4', port=49433): Max retries exceeded with url: /upnp/control/deviceinfo (Caused by NewConnectionError('<urllib3.connection.VerifiedHT TPSConnection object at 0x66849bf0>: Failed to establish a new connection: [Errno 111] Verbindungsaufbau abgelehnt'))

In im (rudimentären) Log der Fritzbox steht: Anmeldung einer unbekannten App von IP gescheitert.

C) Kopie der Plugin Conf aus der Produktivinstanz

fb1:[INDENT]class_name: AVM
class_path: plugins.avm
username: smarthome
password: Fortuna1
host: 192.168.2.4
port: 49443
cycle: 120
ssl: true # use https or not
verify: false # verify ssl certificate
call_monitor: 'True'[/INDENT]

Ergebnis: Geht! Plugin verbindet, sogar parallel mit der Produktivinstanz.

Für mich sieht es so aus, dass das Plugin bei Verwendung des Attibutes plugin_name anstatt class_name und class_path nicht richtig initialisiert.

Bei requests bis ich übrigends bei version 2.22.0.

Hilft das zur Fehlersuche?

[psilo]

klingt zwar ziemlich seltsam, was das mit dem connect zu tun haben sollte, aber ich teste heute abend mal nach. Ich habe alle plugin instanzen noch mit

class_name: AVM
class_path: plugins.avm

drin.

Wobei ich immer noch eher daran glaube, dass die box mal die anfragen packt, mal nicht.

Msinn du verwendest das plugin doch auch, hast du schon umgestellt auf plugin_name?

[Maxthomas2001]

Ich habe nun die Plugin Conf Variante C) von Sisamiwe übernommen, natürlich an meine Daten angepasst.
Ergebnis: Funktioniert!
Lediglich zwei Fehlermeldungen im Smarthome Log:

2020-01-14 06:23:07 ERROR plugins.avm Attribute wan_upstream not available on the FritzDevice
2020-01-14 06:23:07 ERROR plugins.avm Attribute wan_downstream not available on the FritzDevice

Aber das ist doch schon mal ein guter Anfang

[psilo]

Maxthomas2001 nutzt Du das DSL Model der Box? Oder seperat? Das sind halt die Infofelder Deiner Internetconnection.

Zum Pluginname schaue ich nochmal, evtl gebt ihr schlichtweg den falschen Name an. Vielleicht kann Msinn auch nochmal austesten.

[Maxthomas2001]

Ich benutze die Kabelversion 6490 von Vodafone.
Der Fehler ist jetzt nicht so dramatisch. Wichtig ist mir die Steuerung der WLan Verbindungen. Und die klappt.

[psilo]

man müsste mal sehen obs ein fehler oder eher ein warning ist.. bei nem repeater gibt es das attribut ja auch nicht. denke ich bau das für das attribut noch um vom loglevel her.

[Sisamiwe]

Wobei ich immer noch eher daran glaube, dass die box mal die anfragen packt, mal nicht.

Ich habe meine Testinstant bestimmt 20x neu gestartet und mit der Konfig A und C bekam ich immer einen Connect zur Fritzbox

Zum Pluginname schaue ich nochmal, evtl gebt ihr schlichtweg den falschen Name an. Vielleicht kann

Ich habe immer direkt über das Admin Interface die Plugins konfiguriert. Damit habe ich gar keine Möglichkeit, den falschen Namen zu nehmen. Das ist doch alles voreingestellt. Gibt es vielleicht einen Fehler in der avm/plugins.yaml?

[Msinn]

du verwendest das plugin doch auch, hast du schon umgestellt auf plugin_name?

Schon vor mehreren Releases. Du noch nicht???

Der Parameter bestimmt nur wo die Klasse gesucht wird, die Python laden soll (wie die alte Kombination aus 2 Parametern auch). Damit könnte der Parameter höchstens dafür verantwortlich sein, dass ein Plugin nicht geladen wird. Zu vermuten, dass das Auswirkungen auf den internen Ablauf eines Plugins haben kann, bedeutet Python magische Kräfte zuzusprechen. (...und ich glaube nicht an Voodoo )

[bmx]

Das wäre ja auch kein Voodoo sondern Schlangenbeschwörung ;-)

[psilo]

habe alle instanzen auf "plugin_name: avm" umgestellt. Keinerlei Probleme.. Neuster DEV core und DEV plugins.

fritzbox_7590:
    plugin_name: avm
    username: smarthome
    password: ....
    host: 192.168.178.1
    port: 49443
    cycle: 420
    ssl: true # ssl: use https or not
    verify: false # verify: verify ssl certificate
    call_monitor: 'True'
    instance: fritzbox_7590

einziger unterschied, dass ich die instance noch vergebe?! macht das bei euch auch nen unterschied?

[Sisamiwe]

habe alle instanzen auf "plugin_name: avm" umgestellt.

Hast Du das händisch in der plugin.yaml geändert oder auch über das AdminInterface?

Ich bin auf Reisen und kann frühestens am Do Abend testen.

[psilo]

händisch, aber wenn in der yaml das gleiche steht, sollte das doch wurscht sein..

[Sisamiwe]

händisch, aber wenn in der yaml das gleiche steht, sollte das doch wurscht sein..

Im Prinzip schon, wenn das gleiche rauskommt. Irgendwo muss der Unterschied im Verhalten ja herkommen. Der Unterschied kann auch in den Einrückungen der Attribute liegen.
Maxthomas2001
Kannst Du psilos Config aus Beitrag #536 händisch in den etc/plugins.yaml mit Deinen Parametern eintragen und testen?

[psilo]

Sisamiwe da ich die einrückungen seit neustem nicht mal von notepad++ ins forum bekommen habe, einfach vor jeder zeile 4 spaces machen!

Es wäre aber doch relativ abstrus, wenn die einrückungen schuld sein.. ausser das "verify" wird bspw übersehen beim verarbeiten, aber dann sollte es beim yaml parsen ja einen fehler im log geben. habt ihr das gecheckt?