AVM Plugin

[kingolli]

Hallo!

Ich hatte da noch ein Problem bei der Abfrage "is_host_active", da kam immer True, auch wennn der Host in der Fritzbox nicht angemeldet war. Das habe ich (im Rahmen meiner Möglichkeiten) gefixt:

__init__.py Zeile 1002

            [COLOR=#333333][FONT=Consolas][SIZE=12px]is_active [/SIZE][/FONT][/COLOR][COLOR=#A71D5D][FONT=Consolas][SIZE=12px]=[/SIZE][/FONT][/COLOR][COLOR=#333333][FONT=Consolas][SIZE=12px] tag_content[[/SIZE][/FONT][/COLOR][COLOR=#0086B3][FONT=Consolas][SIZE=12px]0[/SIZE][/FONT][/COLOR][COLOR=#333333][FONT=Consolas][SIZE=12px]].firstChild.data[/SIZE][/FONT][/COLOR]

ersetzt durch

            if (tag_content[0].firstChild.data == "1"):
                is_active = True
            else:
                is_active = False

Vielleicht kann das jemand ins Plugin übernehmen oder anpassen.

Grüße
Peter

[psilo]

Ich schaue mir mal heute abend an ob ich das merge. Bin nicht sicher ob ich die Items dazu direkt oder via der Funktion befülle. Via Item funktioniert das Feature definitiv, da ich es bereits aktiv bspw. zur Torsteuerung nutze. Bitte auch noch Angabe welche FB und welches OS.

Danke schonmal für die Auseinandersetzung mit dem Thema ist nicht selbstverständlich gleich den Fix zu liefern!

[kingolli]

Ich schaue mir mal heute abend an ob ich das merge. Bin nicht sicher ob ich die Items dazu direkt oder via der Funktion befülle. Via Item funktioniert das Feature definitiv, da ich es bereits aktiv bspw. zur Torsteuerung nutze. Bitte auch noch Angabe welche FB und welches OS.

Genau das war mein Problem, ein per Logic angetriggerts "sh.fb1._update_loop()" brachte das richtige Ergebnis, "is_host_active" brachte -wie gesagt- was anderes. Und wenn du schon mal dabei bist, könntest du mir mal ein Beispiel für "_update_host" posten, das hab ich nämlich nicht hinbekommen, Fehler war immer "Item ... hat kein Element conf" oder so ähnlich.

Fritzbox ist eine 7490 mit FritzOS 6.51

Danke schonmal für die Auseinandersetzung mit dem Thema ist nicht selbstverständlich gleich den Fix zu liefern!

Danke, gerne.

Grüße
Peter

[psilo]

Also erstmal hast Du recht, da die Methode ein bool zurückgibt, habe ich die Prüfung reingenommen.

das _update_hosts wird ja automatisch aufgerufen und befüllt die Standarditems wie das hier:

[[[iPad]]]
    mac = 96:B9:35:8F:7F:A2
    avm_data_type = network_device
    type = bool
    visu_acl = ro
    avm_identifier = fritzbox_1
    [[[[ip]]]] # no avm_identifier necessary, attributes are parsed via child items
        type = str
        avm_data_type = device_ip
        visu_acl = ro
    [[[[connection_type]]]]
        type = str
        avm_data_type = device_connection_type
        visu_acl = ro
    [[[[hostname]]]]
        type = str
        avm_data_type = device_hostname
        visu_acl = ro

Zum Direktaufrufen ist die nicht gedacht.

PS: Bugfix ist im DEV

[SwenS]

Am Ende vom Wochenende gibts ein neues Feature, sog. Trigger-Items.

Dort kann man ne Quellrufnummer (bspw. Handy) und eine Zielrufnummer (bspw. 3te VOIP Nummer daheim) definieren. Wenn der CallMonitor einen Call registriert, dann prüft er Quelle und Ziel und bei Match setzt er den bool auf true. Beim nächsten Anruf wird der bool auf false resetted und erneut geprüft...

Nutze das jetzt um per Call das Tor zu öffnen. Man muss nichtmal zahlen, weil es ja reicht, dass es 1mal klingelt..

Feature geht bereits und ist aktuell im Test.

[[[trigger]]]
type = bool
avm_identifier = fritzbox_1
avm_data_type = monitor_trigger
avm_incoming_allowed = xxx
avm_target_number = xxx

Hallo,

ich will das Feature bei mir auch einsetzten.
Hab alles soweit am laufen, ausser das es nur genau einmal geht und beim nächsten Call geschied nichts.
Der Bool wird anscheinent nicht resetted.
Kann der Bool beim Auflegen schon auf FALSE reseted werden.

Vielen Dank
S.

[Sandman60]

Nee, bitte nicht, das hatten wir beim Betatesten schon.dafür gibt es enforce_updates = yes, dann löst es auch mehrfach aus.

[psilo]

ja bitte mit enforce_updates = yes..Die README stimmt da noch nicht. Reset dann siehe Codeauszug:

for trigger_item in self._trigger_items:
    trigger_item(0)
    if trigger_item.conf['avm_data_type'] == 'monitor_trigger':
        if trigger_item.conf['avm_incoming_allowed'] == call_from and trigger_item.conf['avm_target_number'] == call_to:
            trigger_item(1)

direkt nach der (1) ein (0) senden hat - warum auch immer - bei mir dazu geführt, dass das Item nicht gezogen hat...

[SwenS]

mit enforce_updates = yes hab ich dasselbe Problem nur das jetzt die Logik zweimal unmittelbar nach einander aufgerufen wird und das nur beim ersten Call. Bei jeden weiteren passiert nichts.
Items

[[[trigger1]]]
type = bool
avm_identifier = fritzbox_1
avm_data_type = monitor_trigger
avm_target_number = ****16
enforce_updates = yes
[[[trigger2]]]
type = bool
avm_identifier = fritzbox_1
avm_data_type = monitor_trigger
avm_target_number = ****17
enforce_updates = yes

Logic aufruf

[Tor_auf]
filename = tor_auf.py
watch_item = fb1.monitor.trigger1 | tor.auf

[Tor_zu]
filename = tor_zu.py
watch_item = fb1.monitor.trigger2 | tor.zu

[Sandman60]

Ohne es geprüft zu haben... Kannst Du mal in die Logik zu Beginn ein

if trigger ['value'] = true

einbauen?

Beim Testen hatte ich mal Situationen wo der CallMon ausgelöst hatte (mit einem false) wenn auf einer der anderen Nummern angerufen worden ist. Damit könnte es klappen...

[SwenS]

die Logik hab ich zum Test so:

if sh.fb1.monitor.trigger1() or sh.tor.auf():
logger.warning("TOR AUF") #nur Test
sh.tor.auf ('on')

beim ersten Anruf (Tor Auf) geht es
jeden weiterer (Tor ZU) nicht mehr.

Ich lass mir die Trigger in der Visu anzeigen, nach dem erste Anruf geht der Trigger nicht mehr auf false...

[Sandman60]

Hmm, ich glaub jetzt dämmerts mir, muß aber psilo was dazu sagen... Bin mir nicht sicher ob die mehrfache Verwendung von monitor_trigger vorgesehen ist, auch wenn es unterschiedliche "avm_target_number" gibt....

[psilo]

Mehrfacher Aufruf ist schon angedacht. Verstehe ich das richtig, dass Du je nach Zielnummer Tor auf oder Tor zu machen willst?

Wo ich unsicher bin ist, ob der Trigger ohne Angabe einer Source Number geht. Ich hatte das eigentlich so gebaut, dass man Source UND Target setzen muss. Alles andere ist untested

also die beiden:

avm_incoming_allowed = ...
avm_target_number = ...

[psilo]

Also es sind immer beide zu setzen. eigentlich dürfte es ohne avm_incoming_allowed gar nicht gehen..

            # process "trigger items"
            for trigger_item in self._trigger_items:
                trigger_item(0)
                if trigger_item.conf['avm_data_type'] == 'monitor_trigger':
                    if trigger_item.conf['avm_incoming_allowed'] == call_from and trigger_item.conf['avm_target_number'] == call_to:
                        trigger_item(1)

[psilo]

Ich habe gerade eine neue Version gepusht, die bei trigger items mit nur einem oder keinem der attribute einen Error rausloggen sollte. bitte mal testen!

[SwenS]

Also es sind immer beide zu setzen. eigentlich dürfte es ohne avm_incoming_allowed gar nicht gehen..

# process "trigger items"
for trigger_item in self._trigger_items:
trigger_item(0)
if trigger_item.conf['avm_data_type'] == 'monitor_trigger':
if trigger_item.conf['avm_incoming_allowed'] == call_from and trigger_item.conf['avm_target_number'] == call_to:
trigger_item(1)

Hallo,
ich hatte bei mir das avm_incoming_allowed raus genommen da ich sonst 10 Rufnummer n für Tor Auf und 10 für Tor Zu vergeben müsste (1 Tor 4 Wohnungen).
Es hat ja soweit funktioniert aber halt nur beim ersten Anruf danach wurde der Trigger nie zurück gesetzt. Erst nach SmartHome restart war er wieder auf Null.