LBS Verhalten beim Systemstart

[wintermute]

Christian, ich braeuchte mal Deinen fachmaennischen Rat

Das betrifft jetzt konkret die Squeeze Bausteine, aber ich denke das Problem tritt auch bei anderen LBS auf...
Situation: Edomi startet neu, an dem Kommando LBS liegen (interne) KOs an (zB 0 fuer Stop, 1 fuer Play). Das erigibt auf jeden Fall einen refresh am Eingang und der Baustein macht jetzt irgendwas. Nach meinen Erfahrungen ist das aber selten das, was gewuenscht ist, weil das KO was dort liegt nicht dem aktuellen Status entspricht, sondern eher dem letzten Kommando.
Anders ausgedrueckt: die Player gehen alle an oder aus, ungeachtet des Status in dem sie sich vorher befunden hatten. Das macht auch keinen Unterschied ob das betreffende KO remanent ist oder nicht, solange da am Schalteingang nicht der letzte Status anliegt triggert der Baustein.

Mein Gedanke war jetzt, die Ausfuehrung nach Systemstart fuer zB 5s auszusetzen, so dass der erste refresh im Baustein ignoriert werden kann. Dazu muesste ich aber wissen, wann der letzte Systemstart war. Das geht bestimmt auch mit Logiken und zusaetzlichen Eingaengen, aber generell waere es charmanter, das direkt im baustein ohne zusaetzliche KOs, also zB mit einer Systemvariable abzufangen.

Vielleicht hab ich da aber auch grad wieder nen Tunnelblick und mache was grundlegendes falsch, aber genrell scheint es mir so, dass Trigger EIngaenge beim Systemstart immer getriggert werden (zumindest solange nur refresh ausgewertet wird).

Hast du ne Empfehlung wie am besten vorzugehen waere? Falls ich mich verstaendlich machen konnte

dank & gruss :: Michael

[gaert]

Aaaaaaalso...

Beim Systemstart werden alle LBS initialisiert, d.h. es wird quasi rückwärts von einer Ausgangsbox ausgehend (als Ende einer Verkettung quasi) alles abgearbeitet. Dies nur am Rande.

Verhalten der Eingänge beim Start von EDOMI:

• jeder Fixwert (sofern !=NULL) triggert
• jedes KO (sofern !=NULL) triggert und übersteuert dann den Fixwert
• jede Verbindung zu einem anderen LBS triggert und übersteuert dann den Fixwert (ein KO kann hier nicht übersteuert werden, weil der Eingang kein KO enthalten kann - ist bereits mit einer Verbindung belegt)
  • sofern die Verbindung "etwas macht" (der Quell-LBS also am Ausgang etwas liefert), wird der Verbindungs-Wert herangezogen
  • liefert die Verbindung keinen Trigger (weil der Quell-LBS am Ausgang nichts liefert):
    • Fixwert triggert (sofern Fixwert !=NULL ist )
    • ist Fixwert ==NULL wird NICHT getriggert (Fixwert fehlt, Verbindung triggert auch nichts, KO gibt es nicht (Verbindung!))
• "Logik-Schleifen" werden i.d.R. erst NACH der Initialisierung gestartet, da keine der Triggerbedinungen erfüllt sein wird
• soll ein LBS bewußt erst NACH der Initialisierung gestartet werden, nimmt man das KO 2 (Systemstart) als Trigger (statt einem Fixwert)

Dein "Problem" habe ich nicht so richtig verstanden... Ein KO triggert selbstverständlich den Eingang (sofern es nicht leer ist), dafür ist es ja mit dem Eingang verbunden. Hilf' mir doch auf die Sprünge

[wintermute]

Hilf' mir doch auf die Sprünge

Noe
Erstmal Danke fuer die Auflistung, hat mich nicht nur erleuchtet sondern auch das Brett vorm Kopf angeknackst...
Der Trick ist (natuerlich) NULL!=0 aber manchmal ist man halt wie vernagelt...

dank & gruss :: Michael

[gaert]

Pffff...

Naja - ist vielleicht auch etwas blöd gelöst (oder besser: verwirrend). Aber was soll man machen? Irgendwie muss ja "leer" definiert sein... Übrigens ist "" und NULL das gleiche in diesem Fall.

[wintermute]

Pffff...

Selba

Naja - ist vielleicht auch etwas blöd gelöst (oder besser: verwirrend). Aber was soll man machen? Irgendwie muss ja "leer" definiert sein... Übrigens ist "" und NULL das gleiche in diesem Fall.

Ich denke die Ursache lag/liegt darin, dass ich
a)im Code bisher einfach nur tumb:

if ($E[refresh]) {
   $E[value] ? "yes" : "no";
} 

verwendet habe und
b) eim Systemstart halt ein refresh kommt
Denkt man drueber nach isses logisch

Aber wegen "" und NULL: heisst das, dass ein Leerstring am Eingang im LBS zu einem NULL wird? Oder andersrum? Oder einfach, dass ein leeres KO (also wirklich leer, nicht 0 oder so) beim Start den Eingang nicht triggert? Nur beim Start? Weil spaeter ja schon, meine ich...

Jetzt hast Du mich naemlich verwirrt.. haett ich ma nich gefragt

[gaert]

Weiß ich gerade "selba" nicht

Doch doch... Jetzt fällt's mir wieder ein

"" und NULL sind das gleiche (beim Fixwert kann man ja auch nicht NULL eingeben, sondern das Feld nur leer lassen - in der KO-Config ebenso (Defaultwert)).

Ein NULL kannst Du per GUI also garnicht erzeugen, sondern nur ein "". In einem LBS könnte man natürlich $xy=null setzen und z.B. auf einen Ausgang "poken". $xy="" würde aber zum gleichen Ergebnis führen.

Ein leeres ("" oder NULL) KO triggert also nicht den Eingang/LBS. Davon darfst Du ausgehen Es sei denn, ich habe irgendwo gepennt bei der LBS-Erstellung - kann man natürlich nie ausschließen...

EDIT:
"" und NULL ist für PHP natürlich nicht das gleiche! Also ein is_null() wird nur bei NULL true liefen. Aber: Beim Setzen von Ausgängen/KOs/Variablen/etc. in EDOMI wird ja letztlich eine Datenbank befüllt - und hier wird "" zu NULL konvertiert (dafür sorgt eine entsprechende Funktion).
Zur "Sicherheit" (oder besser: zur Entwirrung...) könnte ich ggf. die LBS entsprechend abwandeln, so dass im Quelltext nicht "is_null()" auftaucht, sondern isEmpty() - dies ist eine eigene Funktion die einfach prüft, ob eine Variable leer oder NULL ist. Dies würde die Funktion nicht beeinflussen, aber ggf. für weniger Verwirrung sorgen (sofern jemand den Quelltext eines LBS studiert).

[coliflower]

[wintermute]

Ein leeres ("" oder NULL) KO triggert also nicht den Eingang/LBS. Davon darfst Du ausgehen

*lach*
Danke fuer die Antwort (vor allem fuer den nicht zitierten Teil)
Und ja, falls nicht komm ich nochmal meckern

gruss :: Michael

[gaert]

Nur zu!

Übrigens: Wenn man in PHP ein mySQL-Result genauer betrachtet, verhält sich die DB-Engine eigentlich nicht korrekt (wenn Du mich fragst). Wenn das DB-Feld leer ist (also "") wird dies in PHP zu NULL. Wenn das DB-Feld NULL ist ebenso. Schaut man sich aber die DB z.B. mit einem DB-Viewer oder per Shell an, steht tatsächlich "" bzw. NULL in dem DB-Feld. Die DB unterscheidet also auch bei Strings zwischen "leer" und NULL - aber PHP in diesem Fall offenbar nicht. Daher werde ich bei Gelegenheit mal "drübbergucken" und die ganzen is_null()-Funktionen gegen isEmpty() austauschen, denn wer weiß schon so genau, ob die PHP-Jungs dieses Verhalten irgendwann mal abändern und zwischen "" und NULL unterscheiden

@coliflower
Keine Sorge - wird sind (noch) nicht durchgeknallt... oder doch?!

[wintermute]

@coliflower
Keine Sorge - wird sind (noch) nicht durchgeknallt... oder doch?!

Lass Dir nix erzaehlen... "one by one, the penguins..." und so

Übrigens: Wenn man in PHP ein mySQL-Result genauer betrachtet, verhält sich die DB-Engine eigentlich nicht korrekt (wenn Du mich fragst). Wenn das DB-Feld leer ist (also "") wird dies in PHP zu NULL. Wenn das DB-Feld NULL ist ebenso.

Da tu ich dich mal prinzipiell Recht geben (um das in Ruhrpott-Deutsch zu formulieren), allerdings kann man da auch vortrefflich drueber streiten
SQL sagt recht eindeutig "NULL means unknown/missing", aber auch: "NULL is never true, not even when comparing with NULL". Das erste ist einfach, das zweite ist schwieriger programmtechnisch umzusetzen...
Geht man aber davon aus, dass NULL im SQL einfach bedeutet "das Feld ist leer, also wirklich leer, nicht einfach leer, eher existenziell leer", was die meisten Leute ja tun, dann waere NULL definitiv "wahrer" als ein leerer String. Analytisch korrekt umgesetzt ist es aber in keinem Fall, da stimme ich Dir zu.

...wer weiß schon so genau, ob die PHP-Jungs dieses Verhalten irgendwann mal abändern und zwischen "" und NULL unterscheiden

Du hast Dich zum Gleuck fuer CentOS 6 als Basis entschieden, da kannst Du noch bis Ende 2020 sicher sein, dass keine gravierenden PHP Updates reingraetschen
Und selbst CentOS 7 (EOL Mitte 2024) kommt noch mit PHP 5.4... was soll da passieren?

gruesse :: Michael

[saegefisch]

Im "Das große Edomi-Kompendium" werden eure Foren-Dialoge später ein eigenes Kapitel bekommen...

Danke euch zwei! Für Form und lehrreichen Inhalt! Das Leben ist schön...

[wintermute]

Danke euch zwei! Für Form und lehrreichen Inhalt! Das Leben ist schön...

Der Dank geht zurueck

Und weil ich:
1) grad so angenervt davon bin diese unleserlichen (weil url-kodierten) LMS Ausgaben zu lesen
2) Dich das Thema theroetische Informatik ja scheinbar nicht ganz kalt laesst
und last but definitely not least
3) ich dem Christian gern mal etwas Rueckendeckung bei diesen ganzen "Edomi kann das nicht!! WAHHH!" Posts zu geben

hab ich grad mal eine Pause vom Alltaeglichen gemacht und den Baustein 19000159 im Portal hochgeladen.
Es handelt sich dabei um einen Brainf*ck Interpreter als LBS (ohne EXEC-Teil oder externe Aufrufe) dessen Funktion beweisst, dass Edomi Turing-vollstaendig oder zumindest n-while berechenbar ist.
Fuer den Laien formuliert: alles, was man mit Computern machen kann, kann man auch mit Edomi machen! So! Schluss! Schnute halten, setzen!
Ob das dann auch Sinn macht ist im Umfang der theoretischen Fragestellung egal, es geht ums Prinzip. Und das waere dann hiermit belegt...

Man moege mir die Verschwendung der Baustein-ID bitte verzeihen
Und @gaert: es ist eigentlich nicht wirklich Turing-vollstaendig, es ist "nur" ein endlicher Automat. Aber wem ich erzaehl ich das? ¯\_(ツ)_/¯

Ich geh jetzt gleich erstmal ins Bett

EDIT: das mit dem "nur endlicher Automat" hat uebrigens mit der Groessenbeschraekung der internen KOs zu tun. Das musste ich noch loswerden

[starwarsfan]

Ganz grosses KIno hier.

Danke für die sehr interessante Diskussion.

[gaert]

SQL sagt recht eindeutig "NULL means unknown/missing"...

Rischtisch... mySQL ist auch nicht das "Problem" - und unterscheidet wunderbar zwischen NULLl und "": '...WHERE bla IS NULL' oder '...WHERE bla=""' sind unterschiedliche Klauseln. Aaaaaber: PHP(!) (bzw. mysqli-Funktionen) unterscheiden offenbar nicht zwischen NULL und "" bei Werten aus einem SQL-Resultset. Und um hier auf Nummer sicher zu gehen werde ich die entsprechenden Vergleiche mal anpassen (sind ja nicht so viele). Nur für den Fall, dass irgendwann im Jahre 2050 oder so... is klar...

So, jetzt widme ich mich (u.a.) wieder den Turing-Diagrammen...