Inzwischen konnte ich diese Funktionalität mal antestesten. Genial es funktioniert. Das erspart mir viele „Notlösungen“. Gerne würde ich im untersten Stock auf einem Server IPS installieren und eine FHZ1300 laufen lassen. Ich müsste dann über das Netz ca. 25 Instanzen synchronisieren. Ist das realistisch? (Ja wir haben ein 1000er Netz, das sollte nicht das Problem sein) Bei 1-Wire wird ja über 200ms verhandelt. Wie sieht es beim Variabel-Austausch aus? Später soll auch 1-Wire so laufen.
So Alles ist umgestellt. Zum Glück war Ostern. Es nimmt viel Zeit in Anspruch, da zwar Variabeln ausgetauscht werden können, aber keine Instanzen geschaltet werden. Konkret: um meine neun TX im Büro schalten zu können, brauchte es einen Tag Umbau.
Ideen um den Aufwand zu verringern:
über die Variabeln welche einer TX (zb) Instanz zugeteilt ist, wird auch die Instanz geschaltet. So wird alles Synchron gehalten. Ich habe Pyri im Büro und das Webinterface im 3. Stock. D.h. Instanzen können von überall her verändert werden.
Variabelnaustausch in beide Richtungen. Mit entsprechender AntiLoopkontrolle. (damit man keine Loops produziert, ist momentan Denksport gefragt)
-Was mich immer wieder stört, ich gebe den selben Namen für Scripts, Instanzen und Variabeln immer wieder ein. Bei Variabelnaustausch natürlich mindestends 2x. Könnte man da etwas alla Wizard mit über das Netz machen?
übrigens habe ich viel über die Settings.xml direkt gemacht. Wenn ich alles über das offizielle Interface gemacht hätte, wäre ich Übermorgen noch nicht fertig
dann wünsche ich noch fröhliche Restostern; ich teste weiter…
Hmmmm, auf die ersten Fragen gibt es ja nicht wirklich Reaktionen/Antworten. Schade…
Wirkliche Probleme gibt es jetzt mit „‚FALSE‘ is not a valid integer value“ was sicher stimmt, aber manchmal wird die „Lux_WS“ auch richtig übermittelt.
„OnChange“ reicht für den Austausch definitiv nicht. So bekomme ich die Meldedaten meiner Rauchmelder nicht mehr mit. Die sollten ja ihren Status hoffentlich nie ändern. Wann sie sich zum letzten Mal gemeldet haben, interessiert mich trotzdem.
So bekomme ich die Meldedaten meiner Rauchmelder nicht mehr mit. Die sollten ja ihren Status hoffentlich nie ändern. Wann sie sich zum letzten Mal gemeldet haben, interessiert mich trotzdem.
Doch, das wäre schon interessant zu wissen, ob sie noch regelmässig ge-updated werden. Man will ja wissen, ob sie noch leben
es gibt eine andere Lösung, die ursprünglich von einem anderen geschrieben wurde, ich nur nicht mehr den Link im Forum finde. Ausserdem habe ich die Version meinen Bedürfnissen angepasst. Damit lässt sich wunderbar kontrollieren, ob die HMS Geräte-Variablen regelmässig geupdated wurden:
<?
/*
*******************************
IP-SYNCOM Event Scripting
*******************************
*/
//File: WATCHDOG_HMS_SENSORS.ips.php
// Trigger: alle 20 Minuten (1200)
$timeout = 2* 60 * 60; //2 hours
$HMS_Sensor = Array();
$HMS_Sensor[0] = "CENTHEAT_HMS_TEMP"; // Temperature Central Heating
$HMS_Sensor[1] = "BATH1_HMS_GAS_DETECT"; // Gas Detector Bathroom Kids
$HMS_Sensor[2] = "MASBED_HMS_SMOKE_DETECTOR"; // Smoke Detector Master Bedroom
// Liste kann so weitergeführt werden
foreach($HMS_Sensor as $sensor)
{
$sensor_time = IPS_GetUpdateTime($sensor);
if($sensor_time > 0) //found Variable
{
if(($sensor_time + $timeout) < time())
{
SetValueBoolean("HMS_SENSOR_LOST", True);
SetValueString("ALARM_NEW_MESSAGE", "-- ALARM HMS --> SENSOR ".$sensor. " lost");
}
}
}
?>
Wird ein Sensor für 2 Stunden nicht mehr geupdated, wird die BOOL Variable „HMS_SENSOR_LOST“ gesetzt und eine entsprechende Meldung in das Alarm-Log eingetragen „ALARM_NEW_MESSAGE“
Gerne probiere ich mal den Onchange aus und berichte was dabei rauskommt. Allerdings bleibt dann der MSG-Box Fehler bestehen. Der macht mir fast mehr Sorgen, wollte ich sagen.
Vielen Dank. Das Script kann ich gut für meine „normalen“ Feuermelder brauchen. Allerdings löst es mein Problem nicht. Ich weiss ja das die Feuermeldervariabeln über das Exchange-Teil nicht upgedated werden. Variabeln werden nur bei „on Change“ ausgetauscht und das ist bei einem Feuermelder hoffentlich nie der Fall. (er würde dann von false auf true wechseln und für Aufruhr in der Hütte sorgen; sprich es raucht und brennt irgendwo)
Hätte hier noch ein Logfile welches drei Fehler dokumentiert. Den Exchange-Fehler, einen in der Code-Interpretation des alten Webinterfaces und ein RRD-Tool-Fehler.
gruss remo
