Hallo Leute,

habe mir eine Zeitsteuerung für die Bedienung auf meinem Smartphone programmiert, die ich gerne mit euch teile.

Alle notwendigen Infos sind auf Github zu finden:

https://github.com/gsicilia82/Timer_iobroker

Fragen / Probleme / Wünsche können gerne als Issue auf Github oder hier im Thread gestellt werden.

In diesem Thread werde ich auch über zukünftige Updates informieren. Bei Interesse, einfach diesen Thread auf "beobachten" setzen.

Beispiel Screenshots:

Hauptansicht für die Timer

PopUp-View für die Bearbeitung

Neues Update ist hochgeladen:

Changelog 16.07.2020 (Skript + Main-View + Editor-View)

• Selbes Editor-View (PopUp) für mehrer Timer nutzbar! State-Verlinkungen geändert!
• Neue Variable definiert: bgTimerWithRandom (optional) => Random-Minuten auch für gemerkte Timer nutzen?
• Instanz wird im Skript dynamisch gesetzt. Skript in Javascript-Instanz ">0" lauffähig!
• Sollwert-DropDown wurde mit "Reset" erweitert. Im Hintergrund befindliche Timer (gemerkt) können durch diese Sollwert-Vorgabe im nachfolgenden Timer gelöscht werden. Gerät wird nicht aktiv mit Sollwert "Reset" gesteuert.
• Im Mainview State-Verlinkungen zu den drei Buttons "ADD", "DEL" und "EDIT" geändert.

Für ein manuelles Update wird folgendes Vorgehen empfohlen:

• Editor-PopUp neu importieren mit Namen "cardTimerEditor"
• Alte Editor-Views können gelöscht werden
• Drei Buttons im Mainview neu importieren (State-Verlinkungen geändert, auch Bedingungen in Sichtbarkeit). Die einzelnen drei Widgets können hier unten im Post separat geladen werden. Bei neuem Import, bitte beachten, dass die EDITOR-Button Widget-ID im Skript ggf. aktualisiert werden muss.
• Folgende gelb markierte States können gelöscht werden:
  

Widgets.zip

Idee für das nächste Update

• Editor-PopUp entfällt in VIS. Für die Timer-Editierung wechselt die Timer-Tabelle ihren html Inhalt in eine Editor-Ansicht. Somit entstehen ganz neue dynamische Möglichkeiten; temporär nicht genutzte Felder entfallen komplett, Anzahl Bedingungen dynamisch über "+" erweiterbar (bis 5 oder 6 Stück) und wer weiß was mir noch einfällt.
• Optional wird es möglich sein, dennoch ein PopUp zu nutzen (PopUp-Inhalt = 1 HTML Widget). Grund: Wenn die Split-Ansicht genutzt wird (z.B. User Glasfaser), wird im Tabellen-Widget nicht genug Platz vorhanden sein.

Die Umsetzung wird etwas Zeit in Anspruch nehmen. Zunächst den Roh-HTML Code austesten, dass der Editor nach was ausschaut und im zweiten Step diesen Code generisch im Skript erstellen lassen...

@utze86
Habe die erste Version hochgeladen:

https://github.com/gsicilia82/ShellyNimBLE

Bin gespannt, wie gut deine MiBand7 gefunden wird. Bei mir ist es total kurios: Meine GTS4 Mini wird bis auf wenige Ausnahmen in 1-3 Sekunden gefunden. Meine MiBand6 aber nur alle 4-8 Sekunden...

Bin mit dem Projekt noch nicht ganz fertig. Etwas Komfort bei Shelly Plus2PM will ich noch ergänzen (Leistungsmessung wegen autom. Rollo-Kalibrierung).

[Ich will nachher auch prüfen ob ich einen Shelly OTA direkt flashen kann. Dank Github steht ein Link mit der Firmware zur Verfügung. Aber wahrscheinlich wird so etwas direkt unterbunden...
https://github.com/gsicilia82/ShellyNimBLE/releases/download/0.0.1/firmware.bin]
EDIT: Schade, klappt leider nicht mit OTA aufspielen auf original Firmware

@smartboart
Jetzt hab ich es erst gesehen. Dein State Condition1 ist leer. Deshalb die Fehlermeldung. Es gibt ein Trigger im Skript, sobald etwas bei den Bedingungen eingegeben wird, muss ein String erstellt und anschließend evaluiert werden. So schaut der Trigger aus:

    on({id: new RegExp('javascript\\.0\\.Timer\\.' + path + '\\.Editor\\.Cond1Comp' + "|" + 'javascript\\.0\\.Timer\\.' + path + '\\.Editor\\.Cond1State' + "|" + 'javascript\\.0\\.Timer\\.' + path + '\\.Editor\\.Cond1Value'), change: "any", ack: false}, function (obj) {
        var ConditionJSON = JSON.parse(getState("javascript.0.Timer." + path + ".ConditionJSON").val);
        var Cond1State = getState("javascript.0.Timer." + path + ".Editor.Cond1State").val
        var Cond1Comp = getState("javascript.0.Timer." + path + ".Editor.Cond1Comp").val
        var Cond1Value = getState("javascript.0.Timer." + path + ".Editor.Cond1Value").val
        var strCond1 = "getState(\"" + ConditionJSON[Cond1State] + "\").val " + Cond1Comp + " " + Cond1Value
        setState("javascript.0.Timer." + path + ".Editor.Condition1", strCond1);
        if (Cond1State != "" && Cond1Comp != "" && Cond1Value != "") {
            setState("javascript.0.Timer." + path + ".Editor.Cond1Result", eval(strCond1));
        }
    });

Passt hier evtl etwas nicht mit deiner JavaScript Instanz 1 statt 0? Hast du oben im Trigger das angepasst? Hatte ich ursprünglich aus Blockly übernommen, deshalb ist es mit Regexp statt Array...

Weil es ja öfters den Wunsch gab, mehr Bedingungen als 3 Stück zu integrieren, aber der Platz im PopUp Editor nicht viel mehr hergibt (nun max. 4), habe ich mal folgendes statisch erstellt:

Die Bedingungen sind in einem html Widget integriert. Es werden 6 bis 9 Bedingungen möglich sein. Der Vorteil bei dieser Lösung: Die Bedingungen sind im PopUp scrollbar, wer mehr Platz hat, kann das Widget größer ziehen... Rechts bei den Bedingungen ist es (automatisch) entweder eine Select-Box mit auswählbar true/false oder ein Input-Feld mit freier Eingabe-Möglichkeit.

Wäre wahrscheinlich im Laufe der kommenden Woche fertig.
Ich denke, als Mittelweg der aktuellen Lösung "PopUp" und der zuletzt vorgeschlagenen Lösung "komplett in html" annehmbar?

Update ist im ersten Post online:

Changelog 08.08.2020 (Skript + Editor-View)

• Anzahl Bedingungen von 3 auf 9 erweitert
• Bedingungen werden in Editor-View als HTML-Tabelle angezeigt
• Im Editor-View wird nun ENTWEDER Zeile "Zeiteingabe" ODER "Offset" angezeigt.
• Timer-JSON und EDITOR-States werden mit Skript-Update ergänzt

Für ein manuelles Update gilt folgendes:

• Skript ersetzen (wie immer ab markierten Bereich)
• Im Editor View können alle DropDowns, die für die Bedingungen zuständig waren, gelöscht werden. Es wird nun ein html-Widget mit dem Inhalt {javascript.0.Timer.Editor.ConditionsHtml} benötigt. Im oberen Bereich des Editors habe ich eine Zeile eingespart; es wird nun keine Zeile mit "Eingabe nicht erforderlich" angezeigt. Das kann bei Bedarf übernommen werden.
• Das DropDown für die Auswahl "Anzahl Bedingungen" kann bis auf 9 erweitert werden

P.S.: Bin kein HTML-Experte, aber irgendwie habe ich es hinbekommen, dass im HTML der Bedingungen (Editor-View) automatisch bis zur letzten Bedingung runtergescrollt wird. Ich hielt es für sinnvoll, wenn neue Bedingungen ergänzt werden. Falls Nebenwirkungen erscheinen sollten, einfach Bescheid geben.

EDIT: Bug entdeckt... Update kurzzeitig entfernt

EDIT2: Bug behoben. Update hochgeladen.

Bekannte Bugs sind behoben:

• Es ließen sich keine neuen Bedingungen erstellen
• Auswertung für Bool-States und NonBool-States war fehlerhaft
• Split-Ansicht wieder ok. States für die HTML-Split-Ansicht werden nun früher erstellt. Somit ein Workaround für Callback innerhalb CreateState

Lessons learned:
Werde zukünftig meine Tests direkt mit korrekter Umgebung bzgl. path- und instance-Variable durchführen.... Man lernt nie aus.

Korrigiertes Update ist im ersten Post wieder hochgeladen.

@Jey-Cee @Asgothian
Die deconz API liefert ja aktuell die States unter der bekannten fortlaufenden ID. Allerdings wird mit jeder Message über den WebSocket auch die UniqueID (MAC-Adresse) des Sensors / Lichts übertragen. Rein vom Scripting wäre es möglich die Uniqueid zu nutzen. Oder gibt es, abgesehen vom Aufwand der Programmierung, weitere Gründe, die dagegen sprechen?
Bei Sensors wäre die ID unwichtig, da Daten eh nur empfangen werden. (zur Not, wie z.B. Zeit für BWM, könnte Sensors komplett abgefragt werden und daraus die ID entnommen werden).
Bei aktiven Geräten könnte die ID als State unter der Geräte MAC gespeichert werden, da hier später auch über die Rest API aktiv ein State gesetzt werden muss. Über die MAC des geänderten Object könnte dann auf das State mit der ID zugegriffen und ein PUT request über die ID erfolgen.
Nur kurz erwähnt: bin mit meinen Scripting Skills weit davon entfernt einen Adapter zu programmieren. Im main.js verstehe ich einiges nicht wirklich.
Will aber gerne nach den JS Grundlagen auch weiter dazulernen

@wildbill

// erstelle States für Zielwerte
createState("VIS.bleScan.Pino.RawWemos");
createState("VIS.bleScan.Pino.AvgWemos");

// nachfolgend kann auch manuData statt MAC eingetragen werden
// dann müsste unten der Vergleich auf manuData statt mac erfolgen
// z.B. val[dev].manuData.includes(pino) statt val[dev].mac.includes(pino)
let pino = "ed:4b:90:40:e7:ba";

// für Berechnung gleitender Mittelwert
let arrPinoWemos = [0,0,0,0,0,0];


on({id: "mqtt-client.0.bleScan.bett_192_168_192_49", change: "ne"}, function (obj) {

    // Array in val schreiben
    let val = JSON.parse(obj.state.val);
    
    // Array durchlaufen
    for ( let dev=0; dev < val.length; dev++){
        //console.log(val[dev].mac + " | " + val[dev].rssi + " | " + val[dev].manuData);
        
        // Wenn MAC des betrachteten Array Elements oben definierte MAC enthält...
        if( val[dev].mac.includes(pino) ) {
            
            // Schreibe RSSI Wert direkt in das RAW State (oben definiert)
            setState("javascript." + instance + ".VIS.bleScan.Pino.RawWemos", val[dev].rssi);

            // ab hier gleitender Mittelwert über letzte 6 Elemente (kann oben auch größer definiert werden)
            arrPinoWemos.shift();
            arrPinoWemos.push(val[dev].rssi);
            let sum = arrPinoWemos.reduce((a, b) => a + b, 0);
            let avg = (sum / arrPinoWemos.length) || 0;
            setState("javascript." + instance + ".VIS.bleScan.Pino.AvgWemos", Math.round(avg));
        }
    };
});

Habe ergänzende Kommentare hinzugefügt. Sollte hoffentlich selbsterklärend sein. Wenn nicht, einfach nachfragen

@sigi234

Nutze selbst für eine Tabelle das Widget "Basic html". Ein Klasse Beispiel dafür gibt's ja in der mdui Demo von Uhula. Habe mich daran orientiert. Positiv hierbei ist, dass für html allgemein gut im Internet recherchiert werden kann (Farben, Schriften, usw.).

@klaus88
Bist du absolut sicher, dass der Fehler mit diesem State zusammenhängt?
Beim Update des Skripts zur nächsten Version wurde dieser State unnötig, deshalb habe ich diese Bereinigung unnötiger States drin.

Edit:
Wahrscheinlich hatte ich vergessen, überhaupt das Erstellen des States zu entfernen. Deshalb wird es in der letzten Version noch erstellt und anschließend gelöscht.

Lösche die Zeile, wo das State erstellt wird.

@michael-6
Das Projekt ist auf github veröffentlicht, daher kann jeder gerne beitragen. Ich persönlich habe mich noch nicht mit vis2 beschäftigt, daher ist mir noch nicht bekannt, wie die Kommunikation zwischen VIS und Javascript Adapter hergestellt werden kann. Ob es z.B. weiterhin ähnlich funktionieren kann wie bisher. Auch bzgl des Aufwandes für die VIS Widgets kann ich nicht abschätzen.
Wenn es möglich ist, das Projekt zu vis2 zu migrieren, wird es früher oder später migriert werden. Ich nutze es ja selbst auch weiterhin.

@maxpd
Gibt nix neues bzgl UWB. Hab zumindest nichts neues in letzter Zeit dazu finden können. Hab das Gefühl, dass es weiterhin Jahre dauern könnte...

@chris-1
Ähm ja, Play Store. Sorry für deine Mühen
Glaub, ist sogar kostenlos. Zeigt echt viele Infos.

Wem espresense zu träge ist:
Ich nutze für die erste Erkennung einer Anwesenheit mit BWMs. Die Abwesenheit wird dann anschließend über BLE Tracker registriert. Nutze dafür allerdings meine Shelly Plus Devices, habe dafür was eigenes programmiert. Funktioniert aber mit espresense genauso.
Wenn die Trägheit trotzdem zu stark erscheint, kann man mit Apps die Häufigkeit der BLE Advertisements seiner Uhr o.ä. prüfen. Die Android App "nrf connect" zeigt zum Beispiel den Sende-Intervall an.

@ticaki
Triangulation kannst du vergessen, auch wenn du mehrere verwendest. Hatte da mal mehrere Versuche gestartet und es als "gescheitert" beendet.
Was stattdessen funktionieren müsste, ist Fingerprinting:
https://synyx.de/blog/fingerprinting-indoor-positionsbestimmung-mit-bluetooth-low-energy-2-2/

Habe es selbst noch nicht getestet, da ich mich aktuell mit anderen Projekten beschäftige.

@stromie
Seltsam aber kann man nicht ändern. Habe selbe Admin Version und bei JS die 7.1.6.
Da du den Bug ausfindig gemacht hast, werde ich es eben so einbinden. Werde es mit Leerstring umsetzen. D.h. beim Erstellen des States mit "" füllen und später darauf abprüfen. Wer weiß ob null später auch zu Problemen führt.

Danke dir. Hoffe dass der Timer ansonsten wie erwartet funktioniert.

@stromie
Klasse, super analysiert. Dann hat sich das Verhalten anscheinend verändert, wie der Leere Wert eines neuen States interpretiert wird. Werde ich zeitnah auf github aktualisieren. Kurios ist aber weiterhin, dass es bei mir ohne Anpassung funktioniert.
Bist du bei Javascript oder Admin Adapter auf einer Beta Version unterwegs? Würde es gerne bei mir nachstellen. Evtl genügt auch eine Abfrage auf Leerstring statt null.

@stromie

Bei mir startet alles einwandfrei mit original Skript aus Github.

Wie schaut dein TimerJSON aus, wenn Du das Skript gestartet hast? Der State TimerJSON wird vom Skript erstellt und befindet sich Standard unter:
javascript.0.Timer.Devices.TimerJSON

Kannst Du auch ein Screenshot vom State S_DG08_01 erstellen, so wie bereits für den State Trigger_Abend. Meine Vermutung ist, dass dieser State nicht korrekt verarbeitet wird.

Auch hilfreich wäre ein Screenshot von Zeile 285 - 295 im Skript. Ich vermute den Fehler im original Skript in Zeile 289, aber bei dir wird 290 angezeigt, was ich merkwürdig finde.

Falls Du im original Skript im oberen Teil etwas verändert hast, wäre davon ein Screenshot auch hifreich.

@stromie
Kommen die Fehler nach den ersten starts oder wenn bereits ein Timer abgelaufen ist, d.h. wenn der Timer auslöst?
Das letzte Mal habe ich vor Ewigkeiten was am Code geändert. Würde mich wundern wenn es daran liegt.
Kann es später mal testen, beginnend bei 0.

Ich frage nur um sicher zu gehen:
In beiden Aufzählungen sind ausschließlich States enthalten, korrekt? Es dürfen keine Folder, Channel oder Devices angegeben werden.

@smarthome2020
Damit meine ich, in welchen Bereichen sich der Messwert ändert, wenn du die reale Distanz konstant hältst. Würde hier eine konstante Distanz austesten, die einem realen Szenario entspricht.

Ich würde in einem Skript einen Trigger auf den espresense Datenpunkt setzen, den dich interessierenden Wert aus dem JSON extrahieren und in ein Array hinzufügen. Nach x Minuten, Array in Konsole ausgeben.
Einfacher: den Wert direkt in Konsole ausgeben, ohne Array.
Noch einfacher: Mit Adleraugen den Datenpunkt über Notebook Browser beobachten. Mit Mouseover sieht man den kompletten JSON.

Wenn espresense für dein Geschmack zu stark filtert (=etwas träger), dann kannst du den raw Wert beobachten und ggf selbst nachbearbeiten. Die Übertragungsrate von 5s kannst du nicht verändern.