Also, ich habe zunächst versucht, es in Swift zu machen, aber da ich sehr wenig Zeit hatte und bei der iOS-Entwicklung bei null anfing, war es einfach zu viel Arbeit, mich wirklich damit zu beschäftigen (auch wenn mir das bisschen, was ich gemacht habe, gefallen hat und ich schnell einen ersten App-Prototypen hinbekommen habe).
Dann bin ich zu Ionic 2 übergegangen, das ist wirklich mein Fachgebiet, und in 2 Stunden hatte ich eine fast fertige, funktionierende App ^^ Der große Vorteil, den ich gesehen habe, ist, dass ich die gleichen Komponenten wie im Dashboard wiederverwenden kann (z. B. das Wetter-Widget, das sehr sauber ist, kann ich in der App wiederverwenden, es passt super ^^).
Ich werde in Kürze ein paar Screenshots posten, aber im Moment bin ich neben Gladys etwas im Stress, was den Zeitplan angeht
hallo,
frage für später, was macht man, wenn man 2 Häuser hat?
denn die App ist auf ein Haus ausgerichtet, was gut ist, weil es verhindert, dass zu viele Geräte gleichzeitig verwendet werden.
Aber wie geht man vor, wenn man ein zweites Haus verwalten möchte?
andere Frage, wie kann man den Zustand von nicht-binären Geräten ändern?
Hallo!
Tatsächlich kann die App im Moment mehrere Häuser nicht verwalten und außer die Parameter zu ändern gibt es nicht viele Lösungen…
Aber das wird noch kommen ^^
Wie meinst du das? Du hast normalerweise einen Schieberegler, also musst du ihn nur bis zum gewünschten Wert schieben!
Tatsächlich erscheinen deine Gerätetypen in der App als Sensoren, weil sie in Gladys falsch typisiert sind!
Das Problem liegt im Modul und nicht in der App (oder sogar in Gladys)!
Kurz gesagt, du hast binäre Gerätetypen, die irgendwie falsch typisiert sind… (ohne böse zu sein)
Zum Beispiel kann der ok-Knopf nur zwei Zustände haben, entweder 0 oder 1, also hätte er als binary typisiert werden müssen, aber er ist als ok typisiert (was total absurd ist ) Deshalb zeigt dir die App sie auf diese Weise an. Sie versteht einfach nicht, was der Typ ok ist.
Um das Problem zu beheben, kannst du in die Datenbank gehen und manuell ändern, aber das Beste wäre, es direkt im Modul zu korrigieren ^^
Ich verstehe. Aber was soll man angeben, wenn es nicht binary ist? Und wenn man binary für alles angibt, ist das auch nicht gut, weil man dann nicht weiß, welches was ist? Im Moment wird der Identifier nicht für die Anzeige verwendet.
Bah, man müsste eine Art Tasterfunktion in Gladys implementieren, um das Problem zu beheben. Dann hätten wir vier Arten von Gerätetypen, nämlich binary, multilevel, switch (wenn man das so sagen kann) und sensor. Ich schaue mir das mal an
Was das Tracking auf dem Dashboard angeht, ist ein Update in Arbeit (ich arbeite gerade daran) und es wird der Tag jedes Gerätetyps angezeigt, anstatt des Raums, in dem er sich befindet!
Das sollte ein bisschen nützlicher sein, um sie zu finden ^^
Aber im Moment kann ich dir außer etwas Geduld nichts anderes empfehlen
kein Problem, das war vor allem, um die Dinge wieder hochzuladen
Tatsächlich bräuchte man einen „Toggle“, denn einige Elemente sind nur einmalige Aktionen.
Etwas, das auch cool wäre, wäre eine Art Dropdown-Menü. Zum Beispiel für mein Roomba-Modul, wäre es cool, den Modus auszuwählen, in dem man es setzt. Aber das ist schwieriger umzusetzen.
Wie wird das Multilevel verwaltet (was muss man dafür tun?)
Ich denke gerade darüber nach ^^
Mit @C4rlit0 haben wir unser Projekt mehr oder weniger abgeschlossen, also mache ich jetzt die Jagd nach Features, die wir nebenbei implementieren sollten, bis @pierre-gilles kommt, um das alles zu bestätigen ^^
Und tatsächlich könnte das Dropdown-Menü für einige Anwendungsfälle ganz nett sein
Ich schlage vor, dass wir ein Issue auf dem GitHub-Projekt erstellen, damit wir es nicht vergessen
Du musst einfach „multilevel“ in das Typ-Feld eintragen ^^
tien, ich habe es gerade versucht und es wird Probleme geben, wenn man es in binary umwandelt, weil die Funktion gladys.deviceState.createByIdentifier die verschiedenen Gerätetypen binary nicht unterscheiden kann.
Die Funktion deviceState integriert die ID des Device-Typs, zu dem der Zustand gehört… Warum kann er sie dann nicht unterscheiden? Und vor allem, was hat der Identifier mit der Typ-Geschichte zu tun?
lol,
aktuell, wenn wir einen Zustandswechsel für ein Gerät erhalten, führen wir return gladys.deviceState.createByIdentifier() aus, aber darin ist keine Gerätetyp-ID enthalten. Wenn also zwei Gerätetypen denselben Typ haben, wie soll es dann das Update durchführen?
Also, die Kennung hat nichts mit dem Typ zu tun ^^
Und diese Funktion berücksichtigt den Typ des Gerätetyps nicht, weil es ihr egal ist
Und wenn du genauer hinschaust, wirst du sehen, dass sie die Datenbank durchsucht, um den Gerätetyp zu finden, der die Kennung trägt, die du ihr als Parameter übergeben hast, und sobald sie ihn findet, holt sie seine ID, um sie ruhig zu speichern!
Aber Vorsicht, ID und Kennung nicht verwechseln! Das sind zwei verschiedene Dinge!
Und der Typ hat damit auch nichts zu tun! ^^
man braucht die Geräte-ID sowie den Service (normal), aber auch den Gerätetyp. Wenn also mehrere identische Typen in einem Gerät vorhanden sind, wird es schiefgehen.
Zunächst ist es eine eindeutige Anfrage, also kannst du nur ein Objekt zurückbekommen!
Dann hast du recht, ich hatte nicht gesehen, dass der Typ verwendet wird, aber die Anfrage berücksichtigt DREI Parameter, also durchsucht sie die Datenbank nach einem Gerätetyp, der dieselbe Kennung, denselben Typ (daher) und denselben Dienst hat, wie der, den du ihr gibst!
Also ist es unwahrscheinlich, dass du auf den falschen Gerätetyp stößt.
Allerdings ist es natürlich so, dass, wenn du denselben Typ, denselben Dienst und dieselbe Kennung für mehrere Gerätetypen verwendest, sie dir nur den ersten zurückgibt, den sie gefunden hat (also nicht unbedingt den, den du willst), aber da die Kennung jedes Gerätetyps EINDEUTIG sein sollte, sollte es kein Problem geben ^^