Problem Logikeditor Livewerte

[rdeckard]

An diesen LBS wäre ich auch sehr interessiert.
Habe einen LMS am Laufen und (zurzeit) 3 Player auf Basis Raspberry Pi (Hifiberry und picoreplayer). Im Moment kann ich von Edomi nur den Player via HTTP-Befehle steuern. Funktioniert, aber natürlich würde ich gerne auch den Status ausgeben können. (inkl. was gerade gespielt wird)

Falls du also deine Arbeit hier teilen willst, so wäre evtl. ein eigener Thread wünschenswert. Dann könnten wir an deinen Fortschritten teilnehmen.

[wintermute]

Falls du also deine Arbeit hier teilen willst, so wäre evtl. ein eigener Thread wünschenswert. Dann könnten wir an deinen Fortschritten teilnehmen.

Das werde ich sicherlich tun sobald er benutzbar ist. Im Moment stecken da grad mal 2 oder 3 Stunden Arbeit drin, das dauert also noch ein wenig
Ich geb aber Laut sobald rudimentaere Funktionen nutzbar sind.

Ich sollte aber vielleicht im Vorfeld erwaehnen, dass ich das gegen einem 7.9.0 LMS aufbaue - ich kann also nicht garantieren, dass es mit aelteren Versionen dann auch funktionieren wird.

[gaert]

Nur kurz:

KOs/Ausgänge/etc. dürfen max. 200 Zeichen lang sein.

Leerzeichen in #init sind kein Problem:
#init=a b c

[wintermute]

KOs/Ausgänge/etc. dürfen max. 200 Zeichen lang sein.

Urgs, damit wird mein Konzept hoechstvermutlich nicht funktionieren
Besteht eine reelle Aussicht, dass das eventuell irgendwann mal erhoeht werden wuerde?

gruesse :: Michael

[gaert]

Eher nicht... KOs sind nicht dazu gedacht umfangreiche Informationen zu "transportieren", sondern eher dazu, logische Zusammenhänge abzubilden. Alles eine Frage der Performance - wir wollen ja ein schnelles EDOMI, auch mit tausenden Logiken

[wintermute]

Alles eine Frage der Performance - wir wollen ja ein schnelles EDOMI, auch mit tausenden Logiken

Gemaess DB-Struktur ist das als varchar(200) hinterlegt, wenn ich das richtig gesehen habe. varchar ist aus Performance Gruenden natuerlich schon ok (gegenueber text oder blob), aber die Laenge des varchars ist aus Performancesicht eigentlich ziemlich wurscht. Einzig wenn wenn temporaere Tabelle erzeugt oder Tabellen kopiert werden schlaegt sich das im Speicherverbauch nieder, ansonsten ist die Performance abhaengig davon, wie lang die einzelnen Eintraege dann tatsaechlich werden.
Ich bin naiverweise einfach mal davon ausgegangen, dass sie das mit internen KOs aehnlich wie beim HS verhaelt (also irgendwas um 32kB oder was der kann). Technisch wird der varchar in MySQL innerhalb der Tabellenzeile abgelegt und die kann maximal 64kB lang werden. Eine Erhoehung des varchar-Limits (auf zB 32kB) wuerde also nicht wirklich weh tun.
Nicht falsch verstehen, Performance ist gut, wichtig und man sollte immer drauf achten was man tut, aber man muss ja auch irgendwie die Funktionalitaet im Auge behalten. Und jetzt faellt es mir auch wieder ein Die 200 Zeichen haben schonmal Probleme bei den Wiregate-Diagramm-URLs aufgeworfen - glaube ich.

Ich hab jetzt jedenfalls nur die Moeglichkeit das ganze zu lassen (was nicht realisierbar ist ), fuer jedes Radio einen eigenen permanent laufenden Daemon zu bauen (das waeren bei mir zZ 14, die alle Edomi und den LMS unnoetig zumuellen) oder irgendwie "drumrum" programmieren. Also IPC zB... das geht zB mit Semaphoren, auf die schon vor 15 Jahren alle geschimpft haben. Wenn ich stattdessen APC verwenden will, muss ich am System rumpfuschen und anderen koennen den LBS nicht mehr "einfach so" einbinden.

Auch wenn meine Sicht da nicht weniger subjektiv als Deine sein mag, die Gratwanderung Nuetzlichkeit-Performance geraet IMHO etwas aus den Fugen

BTW: wegen der zulaessigen Zeichen in den KOs. Ich finde es inkonsequent (und technisch nicht anchvollziehbar), wieso zB ein ä, aber dafuer kein á zugelassen ist. Entweder alle Umlaute oder keine - keine wuerde ich sinnvoll finden (also quasi ASCII), dann muss man UTF-8 oder Entities kodieren, das waere dann aber eine verstaendlichere Regel die auch programmiertechnisch einfache rumzusetzen waere.

Lange Rede, kurzer Sinn: was wuerdest Du denn zur IPC zwischen Bausteinen empfehlen wenn die internen KOs dafuer rausfallen?

dank & gruss :: Michael

[gaert]

Nee, es geht nicht nur um varchar So einfach ist EDOMI nun nicht gestrickt...

Deutsche Umlaute sind erlaubt, da EDOMI ein deutsches Produkt ist - ich finde das eigentlich sehr eindeutig und logisch.

Die Kommunikation zwischen den Bausteinen (und allen anderen Bereichen) findet quasi über KOs statt. Ggf. müssen die Werte also entsprechend umgewandelt/geparsed werden. Mir ist allerdings die Problematik nicht ganz klar: Ein LBS ist ein Logik(!)baustein, kein "Plugin" für EDOMI. Im Grunde würde es also schon fast genügen, wenn ein LBS nur 0/1 ausgeben könnte

[wintermute]

IC :/
Damit ist die Squeeze Realisierung fuer mich dann erstmal gestorben (bzw. nur via Frickelei fuer intern nutzbar). Schade, zwar nicht technisch aber persoenlich eventuell verstaendlich....

[gaert]

Das Thema KO-Länge/Sonderzeichen ist nicht in Stein gemeißelt, keine Frage. Aber aktuell gehe ich da noch nicht ran... Du musst bedenken: EDOMI ist ursprünglich für mich persönlich entwickelt worden, d.h. ich kenne natürlich die Einschränkungen etc. sehr genau und weiß, was ich machen darf und was nicht. Nun sieht's natürlich vollkommen anders aus Aber derartige Anpassungen brauchen ihre Zeit, da tief verwurzelt. Insbesondere auch das Thema Sonderzeichen... Die "Ajax"-Kommunikation basiert z.B. nicht(!) auf JSON, sondern auf einer eigenen Implementierung (deutlich performanter). EDOMI ist nicht von ungefähr so fix - vergleiche EDOMI mal mit smartVisu

[MatthiasS]

Nur kurz:
KOs/Ausgänge/etc. dürfen max. 200 Zeichen lang sein.

Schade. LMS ist bei mir auch ein Killer-Feature. Habe ich immer drin. Dann muss ich doch wieder den gelben Sack öffnen.

P.S: Beim HS haben wir externen Betatester lange gerungen, bis wir die internen Text-KO auf 10.000 Zeichen hatten. Viele Dinge sind damit dann erst möglich geworden.

[gaert]

Kommt ja auch alles - nur kann ich nicht alles an 1 Tag erledigen

[saegefisch]

Aber warum nicht????