Ich finde -1 ist schon eine sinnvoll, die Alternative wäre noch ein zusätzliches KO.
Noch ein Feature request für das Ende deiner Liste:
Je länger ich EDOMI nutze, um so mehr Dinge fallen mir ein, was man noch umsetzen könnte. Entsprechend häufiger werden Community-LBS eingesetzt und es wäre hilfreich, wenn es im LBS eine Versionsnummer geben würde, eventuell hinter dem Titel ähnlich dem Init bei den Eingängen also so: [name =Titel #version=0.1 ] oder darunter [version =0.1], wenn das verbindlich wäre, könntest Du das mit unter Hilfe anzeigen lassen und im Download-Portal mit eingebunden werden. Damit wäre auch der Grundstein für zukünftige Erweiterungen in Bezug auf automatische oder nur Meldungen zu verfügbaren Updates gelegt...
Ankündigung
Einklappen
Keine Ankündigung bisher.
EDOMI-Releases/Updates | Aktuell: Version 2.03
Einklappen
Dieses Thema ist geschlossen.
X
Das ist ein wichtiges Thema.
X
X
-
Schon implementiertIch hadere noch mit dem Status "-1" (gesperrt), weil dies die Logik ggf. verkompliziert. Andererseits macht es ggf. durchaus Sinn zu wissen, ob der Code zu oft falsch eingegeben wurde...
Einen Kommentar schreiben:
-
So etwas in der Richtung, damit kann man Falscheingaben in einer Logik weiterverarbeiten, oder dem Codeschloss einen roten Rahmen verpassen...
Einen Kommentar schreiben:
-
Wohin senden? Es werden Befehle ausgeführt, wenn der Code korrekt war - andernfalls eben nicht
Aber ich könnte ein 2. KO hinzufügen (so wie bei Dimmer & Co.) und dieses könnte pauschal auf 1/0 gesetzt werden:
1=Codeeingabe ok, 0=Codeeingabe falsch, -1=gesperrt
Einen Kommentar schreiben:
-
Im nächsten Update wird's ein überarbeitetes Codeschloss (Visuelement) geben:- Codeschloss:
- der Code kann nun auch per Tastatur eingegeben werden (auf das Feld unten links klicken)
- der Zifferncode kann nun eine beliebige Länge haben
- der korrekte Code wird nun nicht mehr im HTML-Quelltext der Visuseite offengelegt
Einen Kommentar schreiben:
- Codeschloss:
-
WagoKlemme Ich hab hier nicht rumgekrittelt sondern eine Verständnisfrage gestellt. Zudem kamen(!) mir manche Lösungsansätze eben seltsam vor und ich wollte es gerne verstehen. Das sich hier viele sehr viel Mühe geben um ein stabiles System abzuliefern bekomme ich durchaus mit - genau deshalb wollte ich einmal kritisch hinterfragen, wie man dies als Anwender identifizieren kann um selbst für sich zu entscheiden ob man einen LBS trotzdem einsetzt oder eben nicht. Dann hat man auch gleich einen Ansatz wenns mal instabil wird.
Das würde ich gerne bezwecken, ich möchte verstehen was ich meiner Installation antue und nebenbei ein bisschen PHP lernen.
Wenn das im Forum ein No-Go ist Verständnisfragen zu stellen (die evtl. auch mal kritisch wirken) fände ich das sehr schade und hoffe, dass das die Mehrheit hier anders sieht. Ich wollte hier sicher niemanden bloßstellen, ich kann mir ja nicht alles ansehen und wollte eben Beispiele nennen, damit man mich besser versteht.
gaert danke dir für die wie gewohnt sachlich fundierte Erklärung!
Einen Kommentar schreiben:
-
@crewo
Ich frage mich schon seit dem vorletzten Beitrag von dir was Du eigentlich sagen/erreichen willst ?
Ist es "gut, dass wir darüber geredet haben" oder "gerne wird jemand für dich eine Qualitätskontrolle für Bausteine einführen" ?
Grundsätzlich ist es, in meinen Augen, ein NoGo hier bestimmte LBSen rauszupicken und rumzukritteln. Alle LBS Entwickler opfern (wie gaert) eine beträchtliche Menge an Freizeit. Jeder gibt sein Bestes, halt das was in ihm steckt.
Falls dir ein Baustein nicht gefällt, lass ihn einfach weg und gut.
Nur damit wir uns nicht falsch verstehen. Auch ich achte auf Ressourcenverbrauch. Ich lasse einfach viele Dinge weg...
Einen Kommentar schreiben:
-
Ok verstanden... bin schon ruhig
Wenn ich mehr von PHP verstehen würde, könnte ich das gerne tun... nur ich denke mir geht es hier nicht anders als den meisten edomi-Anwendern, ich kanns halt nicht leisten und muss mich auf die LBS-Macher hier verlassen.
Einen Kommentar schreiben:
-
... Qualitätskontrolle ...
Wie schon zuvor geschrieben, du kannst es verwenden, für dich adaptieren oder selber schreiben ...
Das ist der Vorteil eines offenen Systems :-)
Einen Kommentar schreiben:
-
jonofe Dank für die Erläuterungen - spart mir Zeit und Mühe
@crewo
Das Vorgehen dieser besagten LBS (EXEC-LBS) ist genau richtig so - anders geht es auch garnicht, egal in welcher Programmiersprache"Auf etwas warten" bedeutet immer(!) Schleife. Ob man dies nun "Push" oder "Dämon" oder "Dienst" nennt ist vollkommen egal... Auch Event-getriggerte Systeme (Windows, Linux, macOS, etc.) arbeiten im Hintergrund natürlich mit (Warte)Schleifen, auch wenn es nach aussen hin nicht so offensichtlich ist
Was EDOMI betrifft gibt's 2 Typen von LBS:
- solche, die innerhalb der "Logik-Engine" (ja, auch ne Schleife) aufgerufen und verarbeitet werden - diese dürfen keine (großen) Schleifen enthalten (vergleichbar mit einer SPS)
- und solche, die vollkommen unabhängig als eigene Instanz arbeiten (EXEC) - diese können im Grunde machen was sie wollen (natürlich sollten sie nicht zuviele Ressourcen an sich reißen)
Eine Qualitätskontrolle meinerseits gibt es nur sporadisch, z.B. wenn ich einen LBS selbst nutze. Ansonsten gilt: Ich bin nicht AppleDu darfst gerne die LBS-Polizei spielen! Ich habe dafür schlichtweg keine Zeit...
Einen Kommentar schreiben:
-
jonofe danke für die Erklärung! Zumindest der Sonos-LBS fragt in Dauerschleife ab und der ein oder andere LBS macht da auch ähnliche Sachen. Abgesehen von Performance auf dem edomi-Server müllt man sich halt das eigene Netzwerk zu. Da ein sinnvoller Einsatz von edomi für mich aber von einigen LBS abhängt, machte ich mir eben Sorgen ob das doch alles so eine gute Idee ist solange es hier keine Code-Guidlines und/oder Qualitätskontrolle gibt
Einen Kommentar schreiben:
-
Mir scheint ich habe den Fehler gefunden, ich werde diesbezüglich mal mit Wintermute sprechen, da es diesen Baustein betrifft.
Vielleicht hat sich da zufälligerweiße was getan.
Und es kam mit dem Update von Edomi und dem Baustein etwas durcheinander.
Einen Kommentar schreiben:
-
Also zu meinem UDP-Baustein:
Der läuft nicht in einer Dauer-Poll-Schleife, er wartet auf UDP-Pakete. Das usleep ist drin, damit auch andere Prozesse Zeit bekommen, wenn laufend UDP-Pakete reinkommen.
Wenn ich das als php-Neuling falsch interpretiere, bitte ich um Aufklärung.
Bei manchen Schnittstellen gibt's aber kein Push von extern, da muss man sich mit einem Poll zufriedengeben oder die Anbindung sein lassen.
Einen Kommentar schreiben:
Einen Kommentar schreiben: