RegisterVariablen, Update, Timing, Priorisierung?

Ein paar Fragen zu RegisterVariablen, die die Doku nicht beantwortet. Hat da jemand schon Erfahrungen/Tests oder gibt’s von den Dev’s Aussagen?

1.) Was geschieht eigentlich, wenn auf einer Instanz mit RegisterVariable recht schnell Daten kommen und die PHP-Threads gerade alle beschäftigt sind (oder pro Zeiteinhait einfach mehr Anfragen reinkommen als Threads da sind)?

Gehen Daten verloren oder werde sie „unlimitiert ge-chained“ und warten solange im Systempuffer, bis sie dran sind?

2.) Kann man (und wenn ja, wie) Registervariablen (bzw. deren Scripte) „präferieren“?

Es gibt ja kritische und weniger kritische Anwendungen. Wenn dann, wie oben beschrieben, einige Instanzen (bei mir rechne ich mit 30 Instanzen) da sind, auf denen viel geschieht (Datenlogging, Überwachung, mitschreiben von Zuständen z.B. von Playern), dann wäre es wünschenswert, bestimmten RegisterVariablen eine höhere Prio zu geben als anderen.

3.) Wenn 2.) nicht geht: Hat schonmal jemand selbst solch eine Steuerung für die Priorisierung von Threads gebaut?

4.) RegVars gehen beim Start (respektive beim shutdown?) verloren. Hat jemand da schon etwas entwickelt, um die Daten zu retten, also beim Exit-Script z.B. alles wegschreiben, was noch da ist und beim start wieder einlesen?

Danke
jwka

diese (quasi Realtime-) Anforderungen kann man mit einem „echten“ Modul sicherlich am Besten lösen. Da hat man mindestens einen ganzen Thread unbegrenzt lange für sich alleine. Man kann sich auch weiterhin der vorhandenen Module wie ClientSocket bedienen und auch Daten an weitere Module über deren Interface übergeben sowie eigene PHP-Funktionen zum Zugriff aus dem Web definieren.

Tommi

  1. Es wird gepuffert bis der RAM alle ist :slight_smile:

  2. First In First Out - Für jede Register Variable wird alles seriell abgearbeitet (Siehe Doku). Aber… Du hast ja echt Anforderungen, dass du Skriptlaufzeiten von 30ms bei 10 Threads ausreizt. Tommi’s Hinweis muss ich voll unterstützen. Ich bin mir teilweise auch nicht sicher, ob IP-Symcon die richtige Wahl war. Es scheint mir, dass eine Eigenentwicklung deinerseits vielleicht schneller gewesen wäre, als die tausend Hürden, die IP-Symcon für dein Projekt hat, zu umgehen.

  3. Ich nicht.

  4. Auch hier nicht. Sobald IPS aus ist, hast du eh Datenverlust. Da kommt es ganz sicher nicht auf ein paar Pakete an. Stell dir dann noch die Daten vor, die im internen Register Variable Puffer sind (Problem Frage 1), die noch nicht über die Skripte verarbeitet wurden.

(Dieses Problem in IP-Symcon zu lösen - mit Hilfe von Skripten, die den Shutdown-Vorgang verzögern o.Ä., würde ich nicht einmal Rätselwütigen Jugend-Forscht Kindern zumuten wollen.)

Wenn du ganz sicher gehen willst, würde ich doch lieber ein externes Zwischenprogramm entwickeln, welches Daten puffert und mit IP-Symcon austauscht (mit Handshake), sodass du garantieren kannst, dass alle Daten verarbeitet wurden. Auch bei IPS Downtime. Siehe dann aber Punkt 2 -> Eigenentwicklung.

paresy

PS: Wenn ich den Aufwand sehe mit dem du überall versuchst alles 100% sicher zu machen (was ich nicht verurteilen will - es ist bei bestimmten Sachen angebracht) verstehe ich aber nicht, (und ich werde es wahrscheinlich niemals tun), wie du jemals FS20 eine Chance gegeben hast (und es immer noch nutzt), was ja mal das Unsicherste, und am wenigsten Verfolgbare System von allen ist. Ich hab sogar schon einmal gehört, dass Leute glauben du willst mit nem Trabbi die Mondlandung machen :smiley:

Danke für die Hinweise.

@paresy:

Ich habe tatsächlich schon über eigene Entwicklung nachgedacht (dann aber eines ganzen Homeautomation-Servers und mit Investment-Kapital). Geht hier zu weit.

Bei mir ist der Hintergrund da etwas tiefer als „nur das eigene Haus“. Ich habde vor, mit Dokotik Geld zu verdienen und bin noch am Sondieren, wie: Ob „and der Front“, also beim Kunden, „in the middle“, also als Programmierer und Oberflächengestalter für andere Installer (die ganz häufig nicht so arg viel Ahnung von IT und schon gar nicht von Oberflächengestaltung haben oder als Hersteller (s.o.).

Mein Haus hier ist einfach nur Probierobjekt für exisitierende Sachen, damit ich Leuten nichts verspreche, was dann nicht geht. Daher tue ich auch Grenzen ausloten, die für „mein Haus“ wohl gar nicht relevant sind, aber wenn Du code für Dritte schreiben willst, plötzlich eine ganz andere Wichtigkeit haben. Deshalb auch die strikte Trennung zwischen Code und Daten --> keine Arrays sondern Objekte, die ich zur Laufzeit auslesen kann, etc.

Unter „echtem Modul“ versteht ihr wahrscheinlich eine Eigenentwicklung mit der IPS-API und das dann als „jwka-Modul“ einzubinden?

Naja, dann kommen bestimmt nochmehr solche Fragen wie „was geht“, weil ich natürlich nicht Massen an Zeit versenken will, um dann nach vielleicht einigen Monaten aufgeben zu müssen.

Und zuletzt:
FS20 hat historische Gründe. Und wenn man mal ein paar Tausend in Komponenten versenkt hat, wird’S schwer, davon wieder weg zu kommen - ich bin dann doch zu sparsam. Naja und noch was: Alles vergleichbare kommt dann doch sehr schnell doppelt so teuer oder teurer … nach meinen recherchen. Nu geht’s aber weg vom Thema.

jwka