Script zur Signalprüfung unter Lollipop

[Lachgas]

ok. hab hier ein HUAWEI Honor 7 und möchte den Signalabbruch des GSM Netztes per TASKER prüfen.

Von den nötigen Variablen funktioniert - warum auch immer - %AIR u.%CELLSRV
"Cell Signal Strength" gibt immer den Wert "-1" zurück und entfällt daher wohl. Ach ja, es gibt kein Root!

Hab mich bisher mit nachfolgendem Script rangetastet. Könnte das bitte jemand mal überfliegen und mir schreiben, wo ich da Verbesserungspotential habe. Das wäre echt nett!

Mein Script:

IF %AIR eq on
STOP
IF %CELLSRV neq service
NOTIFY SOUND "Alarm wegen Signalverlust" alarm.ogg
WRITE FILE gsm.log /append on / %DATE;%TIME;%CELLSRV
END IF
STOP


Damit wird nun im Profile alle 3 min. dieses Script abgearbeitet. Sobald aber der "AIRPLANE MODE" auf "on" steht, unterbleibt der Alarm. Das Ereignis wird in der Datei "gsm.log" aufgezeichnet.


Wenn da noch was geht, oder eine bessere Syntax extistiert, würde ich mich über DEIN Feedback freuen!

 

[androidkoller]

Hallo,

ich würde den Task nicht zyklisch aufrufen, sondern %CELLSRV in einem Profil überwachen:

Profile MonitorGsm
State: Variable Value, %CELLSRV neq service

Enter: GsmSignalLost
A1: STOP, If %AIR eq on
A2: NOTIFY SOUND "Alarm wegen Signalverlust" alarm.ogg
A3: WRITE FILE gsm.log /append on / %DATE;%TIME;%CELLSRV

Grüße, Jürgen.

Edit: Wenn das denn unter Lollipop funktioniert... Getestet mit 4.4.2.

 

[Lachgas]

benötigt (D)ein Profil dauerhaft betrieben nicht einen höheren Akkudrain als ein nur 20x i.d.Std. aufgerufener Loop? Ich hatte aus diesem Grund den Timer verwendet um ein vernünftiges Verhältnis aus Stromverbrauch ; Nutzen und Gebrauchsfähigkeit zu halten.

Mein Script hat bisher auch funktioniert. Da Deines ja auch nur etwas eleganter daher kommt und auch weiter keinen anderen Befehle verwendet, denke ich es wird ebenfalls funktionieren. Werd’s mal testweise laufen lassen.

 

[androidkoller]

benötigt (D)ein Profil dauerhaft betrieben nicht einen höheren Akkudrain als ein nur 20x i.d.Std. aufgerufener Loop?

Das weiß ich nicht...

 

[Lachgas]

@androidkoller
ok, Dein Vorschlag hat bisher den Nachteil, dass schon ein Fahrstuhl oder Kellerbesuch (TG) ihn auslöst.
Ich muss also einen Weg finden, die Überprüfung im Entscheidungsfall nach einer Minute zu wiederholen und dann erst Alarn zu geben.
Wie kann ich da evtl eine Variable einbringen die einem "Count-Befehl" ähnlich ist und erst jeweils beim 2.ten Mal auslöst?
Also in ungefähr: Bedingung erfüllt = Counter +1 /nochmals Bedingung erfüllt = Counter +1 nun Vergleich Variable %Zähler= 2 goto Sprungmarke "Alarm" Also ungefähr so:

Spoiler

IF %counter !Set
VARIABLE SET %counter to 0
ENDIF
IF %AIR eq on
STOP
IF %CELLSRV neq service
VARIABLE ADD %count,1
IF VARIABLE %count= 2
NOTIFY SOUND "Alarm wegen Signalverlust" alarm.ogg
WRITE FILE gsm.log /append on / %DATE;%TIME;%CELLSRV
VARIABLE CLEAR %count
END IF

Bin ich da schon richtig unterwegs? Ich würde mich über Hilfe wirklich freuen!!!
Bin halt nicht so der Script-Junkie!!!

LG.

 

[androidkoller]

ok, Dein Vorschlag hat bisher den Nachteil, dass schon ein Fahrstuhl oder Kellerbesuch (TG) ihn auslöst.

Ich dachte, das wäre Zweck des Ganzen Bei deinem ersten Ansatz kann das Signal ja im Extremfall 2:59 Minuten weg sein, ohne dass du es mitbekommst...

Nun ist das aber vermutlich eine echte Verschlechterung, da nun ja Tasker mehr als 1 min. pro zyklus laufen muss!

Nach Aussage des Entwicklers wird bei einem Wait intern ein Alarm gesetzt und sollte also nur geringe Auswirkungen auf den Stromverbrauch haben:

[Q] Is my assumption correct that the "Wait Action" isn't causing much battery drain while the action is waiting?
[A] Correct, it just sets an alarm.

Google Groups



Wie gesagt, weiß ich nicht welche Variante jetzt akkuschonender ist und kann da auch nur Vermutungen anstellen. Die Variable %CELLSVC ist im Userguide als "monitored" deklariert, muss also schon irgendwie von Tasker überwacht werden, wenn man den Variable State Context verwendet (Intervall?). Das wird aber im Hintergrund erledigt. Aufruf und Ausführung eines Tasks erzeugt hingegen deutlich mehr Overhead (Logging etc.), würde ich meinen. Aber wie gesagt, das sind alles nur Vermutungen...


Grüße, Jürgen.

 

[Lachgas]

@androidkoller
Danke, dass Du Dich damit nochmals beschäftigt hast!

Da mir das Fahrstuhl und Tunnelgebimmel doch etwas auf den Dings ging, hab ich nochmals an meinem Script rumgeschraubt! Aktuell hab ich es so gehalten:

Spoiler

Check GSM
A1: If [ %AIR eq on ] (Prüfung ob Flugmodus an oder nicht)
--- A2: Stop [ With Error:Off Task: ] ( bei Status "Flugmodus an" dann Task = off)
A3: End If
A4: If [ %CELLSRV neq service ] (GSM Status abfragen - bei ungleich "service weiter sonst nicht)
A5: If [ %counter !Set ] (Variable %counter prüfen)
--- A6: Variable Set [ Name:%counter To:0 Do Maths:On Append:Off ] (Wenn %counter nicht vorhanden, dann erzeugen mit Wert "0")
A7: End If
A8: Variable Add [ Name:%counter Value:1 Wrap Around:0 ] (Zähler für Durchlauf um 1 erhöhen)
A9: If [ %counter = 2 ] (Wenn Variable %counter = 2 dann weiter)
----- A10: Notify Sound [ Title:Alarm wegen SIGNALVERLUST Text:%DATE-%TIME Icon:null Number:0 Sound File: Priority:3 ] (Alarm/Nachricht ausgeben)
----- A11: Write File [ File:GSM.log Text:%DATE;%TIME;%CELLSRV Append:On Add Newline:On ]
----- A12: Variable Clear [ Name:%counter Pattern Matching:Off ] (Variable %count löschen)
A13: End If
A14: End If

Das wird dann per Profil alle 3 Min ausgeführt. Es wird aber erst beim zweiten negativen Durchlauf Alarm geschlagen. Also spätestens ab der 6 Minute Offline. Das reicht in meinem Fall auch für nen Tunnel Wenn der Flugmodus an ist wird dasScript abgebrochen.

Kannst Du ggf. nochmal sehen, ob ich alle If -> Endif Schleifen richtig abgeschlossen habe.

Edit: Tante Edit hat mir einen Spoiler gekauft

 

[LenovoP780]

Ich würde die ersten 3 Aktionen beim Profil als Trigger einbauen.

Edit: Sicher, dass dein Counter so funktioniert?

 

[androidkoller]

Wenn ein If-Block nur eine Aktion enthält, kann man das in eine Aktion packen. Also nicht

A1: If [ %AIR eq on ]
A2: Stop [ With Error:Off Task: ]
A3: End If

sondern

A1: Stop [ With Error:Off Task: ] If [ %AIR eq on ]

Dann wird das schon mal deutlich übersichtlicher...

Grüße, Jürgen.
[DOUBLEPOST=1444411689,1444410989][/DOUBLEPOST]... und zur Nettiquette in Internetforen gehört es auch, dass man nachträgliche Änderungen in Beiträgen deutlich markiert, insbesondere wenn andere diese schon kommentiert haben

 

[Lachgas]

mag sein, dass mir die ein oder andere Umgangsform noch fehlt!
Die Codeoptimierung habe ich eingepflegt! Danke dafür! Geht da sonst noch was?

Beim Tracen mit div. Popup Printbefehlen hat die Funktion des Scripts tadellos funktioniert allerdings erst nachdem die Variable "%counter" zu "%Counter verändert wurde!.

jetzige Form des Scriptes: aufgerufen über "Profiles" per Timer alle 3 Min

Spoiler

Check GSM
A1: Stop [ With Error:Off Task: ] If [ %AIR eq on ]
A2: If [ %CELLSRV neq service ]
A3: Variable Set [ Name:%Counter To:0 Do Maths:On Append:Off ] If [ %Counter !Set ]
A4: Variable Add [ Name:%Counter Value:1 Wrap Around:0 ]
A5: Notify Sound [ Title:Alarm wegen SIGNALVERLUST Text:%DATE-%TIME Icon:null Number:0 Sound File: Priority:3 ] If [ %Counter > 1 ]
A6: Write File [ File:GSM.log Text:Signalverlust am %DATE um %TIME Grund: %CELLSRV Append:On Add Newline:On ] If [ %counter > 1 ]
A7: Variable Clear [ Name:%Counter Pattern Matching:Off ] If [ %Counter > 1 ]
A8: Stop

Das Geheimnis war die Umwandlung von %counter in eine globale Variable durch Änderung des Anfangsbuchstabens in Großschrift! Ansonsten wurde nach dem ersten Durchlauf des Tasks die Variable neutralisiert und erreichte nicht den Status "2"!

Edit: Tante Edit hat miŕ einen Spoiler gekauft.

 

[cramu]

Wie gesagt, weiß ich nicht welche Variante jetzt akkuschonender ist und kann da auch nur Vermutungen anstellen. Die Variable %CELLSVC ist im Userguide als "monitored" deklariert, muss also schon irgendwie von Tasker überwacht werden, wenn man den Variable State Context verwendet (Intervall?). Das wird aber im Hintergrund erledigt. Aufruf und Ausführung eines Tasks erzeugt hingegen deutlich mehr Overhead (Logging etc.), würde ich meinen. Aber wie gesagt, das sind alles nur Vermutungen...

Korrekt!

 

[Lachgas]

ok, dann also neuer Ansatz! Vielleicht mit weniger Drain u Log

Profil:
[Variable Value %CELLSRV !~ service] startet Task: Monitor gsm

Monitor gsm Task:
A1: Stop [ With Error:Off Task: ] If [ %AIR eq on ]
A2: Notify Sound [ Title:Alarm wegen SIGNALVERLUST Text:%DATE-%TIME Icon:null Number:0 Sound File: Priority:3 ]
A3: SAY Text "Achtung Verbindung verloren!" Engine: Voice default:default
A4: Write File [ File:GSM.log Text:Signalverlust am %DATE um %TIME Grund: %CELLSRV Append:On Add Newline:On ] If [ %counter > 1 ]
A5: STOP

Wie bekomme ich es nun hin, dass ich auch eine Nachricht bekäme sofern das Signal wieder vorhanden ist? So wie beim (guten) NAVI auch?
Hat jemand Vorschläge zu machen?
Evtl. mit eingebettetem "If" Befehl? Oder auch "PerformTask" Sollte aber auch eine nicht so Akkubelastende Warteschleife haben um nicht andauern rausgeklingelt zu werden.

Also: Profil-Auslösebedingung erfüllt -> Task-Aufruf Monitor gsm( darin Alarm ausgeben +Bedingung prüfen für weitere Abarbeitung oder erneuten Start von Task Monitor gsm)
Wenn Status "service" wieder erreicht wurde, darüber eine Meldung rausgeben. Dann zurück auf Überwachung!

Ich wäre Euch sehr dankbar, wenn da noch etwas Input käme.

 

[androidkoller]

Einen Exit-Task hinzufügen, der wird dann ausgeführt, wenn das Signal wieder da ist.

Grüße, Jürgen.

 

[Lachgas]

hmmm...

bin bis hier gekommen:
Auswertung GSM Verbindung
A1: Stopp [ (Fehler):Aus Task: ] If [ %AIR gl on ]
A2: Benachrichtigungston [ Titel:GSM Verbindung verloren! Text:%DATE-%TIME Icon:null Nummer:0 Sound Datei:Ringtones/MeinPfeifen.MP3 Priorität:5 ]
A3: Vorlesen [ Text:Achtung. GSM Verbindung verloren! Maschine: Stimme:default:default Stream:3 Tonhöhe:4 Geschwindigkeit:5 Respect Audio Focus:An Network:Aus sofort mit Task fortfahren:Aus ] If [ %CELLSRV ungl service ]
A4: Schreibe Datei [ Datei:GSM.log Text:Signalverlust am %DATE um %TIME Grund: %CELLSRV Hinzufügen:An Neue Zeile Zufügen:An ] If [ %CELLSRV ungl service ]
A5: Warte Bis [ MS:1 Sekunden:0 Minuten:0 Std.:0 Tage:0 ] If [ %CELLSRV gl service ]
A6: Benachrichtigungston [ Titel:GSM Verbindung vorhanden! Text:%DATE-%TIME Icon:null Nummer:0 Sound Datei:Ringtones/MeinPfeifen.MP3 Priorität:5 ]
A7: Vorlesen [ Text:Achtung. GSM Verbindung vorhanden! Maschine: Stimme:default:default Stream:3 Tonhöhe:4 Geschwindigkeit:5 Respect Audio Focus:An Network:Aus sofort mit Task fortfahren:Aus ]
A8: Schreibe Datei [ Datei:GSM.log Text:Signal gefunden am %DATE um %TIME Grund: %CELLSRV Hinzufügen:An Neue Zeile Zufügen:An ] If [ %CELLSRV gl service ]
A9: Stopp [ (Fehler):Aus Task: ]

Was bisher gut funktioniert, aber vielleicht noch etwas hollprig wirkt! Vor allem der blaue Teil in A5 ist evtl noch etwas ungeschickt programiert!:blushing: läuft aber.

Meine Versuche mit einem "exit Task" gingen bisher schief, weil ein vorhandenes Signal ja sonst die Regel ist und die Bedinngung so unermütlich erfüllt wird! Die Rückmeldung sollte aber nur nach vorrangegangenem Signalverlust angezeigt werden. Vielleicht müsste da noch eine operative ZustandsVariable rein die im Verlust Fall erst auf "1" geht, und in der Wiedererlangung des Signals geprüft werden müsste.
Hoffe mein Brainfood kommt richtig rüber!

An der Arbeitsweise meiner Bastelei hab ich bisher nix negatives bemerkt. Möglich, dass durch "A5" der Batterydrain etwas höher wird da das ja wohl ein Loop ist bis das SIgnal wieder da ist.

 

[androidkoller]

Mit diesem "Warte Bis" Befehl kann ich mich nicht so richtig anfreunden. Wobei laut Doku hier ja auch batterieschonend gearbeitet wird:

Stop executing the current Task until the condition is met. Wait *maximally* the specified time between checks. The actual time between checks will vary because Tasker will opportunistically retest the condition at times when battery life will be unaffected.

Note: a very small wait period might have battery life implications, in general it should be as large as is acceptable.

Ich würde aber persönlich die Variante mit zusätzlicher Variable und Exit-Task bevorzugen...

Grüße, Jürgen.

 

[Lachgas]

ok, hab den ganzen Nachmittag rumgetüftelt, und noch so einiges verbastelt.
Die Kurzform:
Profil:
GSM Überwachung
Ereignis: Variable setzen [Variable: %CELLSRV Wert:* User Variables Only:Aus]
Eingang: GSM wird ausgewertet
A1: Vibrieren [Zeit200]
A2: Beep:[Frequenz:2300 Dauer:500 Amplitude:100 Stream:3]
A3: Vorlesen [Text:GSM Status geändert auf %CELLSRV Maschiene:Stimme:default:default Stream:3 Tonhöhe:4 Geschwindigkeit:5 Respect Audio Focus:An Network:Aus sofort mit Task fortfahren:Aus Task Weiter Ausführen nach Fehler:An]

Somit wird bei jeder Veränderung des Funkstatus eine Meldung ausgegeben.
Leider hat die Sache einen Haken! Während der Verlust des Signals umgehend angesagt wird, werden zwar die weiteren Änderungen angezeigt, da sich die Variable %CELLSRV zwischenzeitlich aber leider nicht ändert (!!!) Stimmt die nach einer Änderung gemachte Aussage nicht mit dem durch den Balkenindikator ausgewiesenen Zustand überein! Per Popup habe ich die Variable ausgelesen! Dabei fällt auf, das der Status nach Einschaltens des Flugmodus auf "NoPower" wechselt (was ja auch stimmt!) dann nach AUfhebens des FM auf "NoService" wechselt, dann aber nicht auf "Service" weiterspringt, sondern auf "NoPower" und/oder auf "NoService" wechselt, obwohl augenscheinlich bereits der Service wieder da ist!
Offensichtlich stimmt die Initialisierung oder der Refresh der Tasker Variablen wohl nicht mit dem Timing der Realität überein.

Dieses Problem hatte sich allerdings auch mit allen anderen Scriptkonstellationen gezeigt!!! Die Variable wird offensichtlich nicht andauernd aktualisiert sondern nur bei Beendens der App oder bei Einschaltens des Screens. Vorschläge dazu?


ggf. wechsle ich sonst mal auf eine andere App (Automate von LamaLabs)

 

[androidkoller]

Funktioniert bei mir wie erwartet und ohne Verzögerungen... Samsung S5 mini, Android 4.4.2, root.

Grüße, Jürgen.

 

[Lachgas]

ok. ist dann also ein gerätespezifisches Probelm was dann so wohl nicht zu lösen ist.

BTW: Ich habe Tasker nun von meinem Honor7 gelöscht.
Die App: "NoCoverageAlert" macht den gleichen Job (siehe Titel!) und das für lau und ist auch nur 25,4Kb gross!
Die Meldeproblematik von Noservice etc. beim Honor7 besteht aber weiterhin und liegt daher tatsächlich am ROM!