Und die eigene Postleitzahl ist gern genommen 
.
Genau, hatte ich ja schon aufgeführt! Hätte nicht gedacht das man die so oft in Skripten verwurschtelt 
Was noch komisch ist die -1 bei Webfront’s, ist das normal?
Noch 16 Instanzen, die meisten sind aus irgendwelchen Tests und bewusst deaktiviert und 37 Scripte mit Fehlern.
Schönes neues Spielzeug 
.
siehe weiter oben im Script
ggfs. gibt es einen falschen Fehler bei WebFront-Visulaisierungen, siehe Problem mit IPS_GetReferenceList()
einfach in der Webfront’s die fehlenden Kategorien setzen bzw löschen. Da gabs früher den Wert -1 für „nicht gesetzt“ …
demel
so,
- mit Sortierung der Meldung
- bei Prüfung in Scripten nun auch mit Zeilennummer
- Meldungen eindeutiger („existiert nicht“ statt „nicht vorhanden“)
was jetzt noch fehlt ist die Prüfung der Ablaufpläne, da mache ich (hoffentlich) morgen weiter.
das kann ich nicht wirklich nachvollziehen
a) Script-Dateien sind nur dass als „ungenutzt“ gekennzeichnet, wenn es kein Script-Objekt in IPS gibt, also völlig unnütz sind
b) wenn ich ein Script nicht check will, dann einfach in der Konfiguration eintrage
ja und nein.
zum einen würde mir die Meldung dann zu überladen sein und ist ist ja so, das es doch das Ziel sein muss, das die Meldungen weg kommen, d.h. entweder die ID eintragen oder die Zeile kommentieren.
D.h. man muss ja nur einmal in das Script um zu prüfen und/oder kommentieren.
Zu ignorierend ID’s in die Listen einzutragen ist auch nicht unbedingt so ganz doll, denn jede Zahl kann ja auch als reguläres IPS_Objekt existieren (auch die 86400) und deren Prüfung würde ich persönlich ungerne generell unterdrücken - eben eher nur an der einen Stelle im Script, wo ich diese speziell Zahl nutze.
Ahh, jetzt eine Insel
Da Mobil bei diesen WF deaktiviert ist, war auch keine Kategorie gesetzt!
Damit sind jetzt auch die komischen ID Fehler von oben (Post 98) weg
Danke, super Teil!
Du bist der Hammer 
.
Jetzt werden auch alle Meldungen eines Scripts ausgegeben, somit sind meine 37 gerade zu 122 geworden 
.
Was mir noch aufgefallen ist, wenn er eine ungültige ID in einem Script findet hört er anscheinend auf im Skript weitere zu suchen.
Das wäre natürlich schön alle Fehler zu finden
Danke & Ciao
Heiko
Das scheint mit dem letzten Update von vor ein paar Sekunden 
anders zu sein ;-).
versuch es nochmal aktuell.
mir war das vorhin auch aufgefallen. was er nich nicht richtig erkennt sind mehrer ID’s in einer Zeile.
Da muss ich noch „hirnen“.
demel
Moin,
Ja ab 5.6/6.0 hat symcon den Namen geändert.
Edit: Jetzt weiß ich auch woher ich das Problem kannte. Als ich auf 5.6/6.0 umgestiegen bin hatte ich es dir mal bei Discord gemeldet.
Ralf
Ich schaue mir das mal an. Da fehlt bestimmt nur eine Definition
paresy
Komme leider heute nicht mehr dazu, aber @ralf hat es ja schon positiv bestätigt
Mache morgen weiter, sieht bei mir ganz sauber aus
Danke fürs schnelle Reagieren
Heiko
Moin Demel,
soo, Update gefahren, getestet und für gut befunden
Funzt mit mehreren ungültigen IDs! Top
PS: Was bewirkt „Ergebnis der Prüfung speichern“ - hab noch nicht mit rumgespielt, fiel mir nur gerade auf - obwohl deaktiviert wird das Ergebnis ja in Variablen geschrieben?!?
Gruß Heiko
Moin Demel,
Mail mit deinem Script arbeitet perfekt.
Dank Ralf
es geht hier um das komplette ergebnis, also auch die meldungen und zähler in einer json-struktur in eune weiter variable
war erstmal mehr zur verfolgung/debugging gedacht, aber dann habe ich es drin gelassen.
demel
1 „Gefällt mir“
Zum nächsten RC gibt es dann SCRIPTTYPE_FLOW mit dem Wert 1
paresy
Ich verstehe die Bewertung nicht komplett. Das ist nur ein Auszug aus dem Code ;-).
switch ( $_IPS['EVENT'] ){
case "39134":
$InstanceID = 57484;
break;
case "00001":
$InstanceID = 00002;
break;
00002 wird gemeldet, 00001 nicht
39134 existiert, wird aber vermutlich nicht geprüft, so wie 00001
57484 existiert