OK,der hat ja noch gar nichts…
Bitte in zeile 198 von V0.4 ein Gleichheitszeichen hinzufügen
if ($total_cnt>=$total_cnt_last)
Tommi
Genial, funzt super!
Frage: Wo stelle ich ein in welche „Basiskategorie“ die einzelnen Variablenbäume angelegt werden?
das steht in $catname in jeder Sektion,z.B.
$catname='EM1010CUL';
Diese wird immer unterhalb Kategorie 0 (normalerweise „IP-Symcon“) angelegt.
Tommi
Ich würde gerne die ganzen „Sektionen“ nicht in Kat 0 (also im Root) haben sondern in einer anderen Kategorie.
dann muss man die Funktion „get_ips_vars“ ändern.
In Zeile 846 ist die Such-Root als 2. Parameter eingetragen, in Zeile 851 der Parent für die Anlage ebenfalls als 2. Parameter.
//Zeilennummern in V0.4
//846
$master=@IPS_GetObjectIDByName($cat,0);
...
//851
IPS_SetParent($master,0);
Tommi
Okay, danke!
Eine zweite Anregung: Für die einzelen Devices wäre es besser statt Kategorien gleich „Dummy Instanzen“ anzulegen. Dann kann man die ganze Instanz per Link einfach einer Kategorie zuordnen; ist für das Webfront einfacher.
Beispielscript hier:http://www.ip-symcon.de/forum/f52/fhz-vollstaendig-empfangen-senden-cul-cun-o-ersetzen-12586/index2.html#post105704
Tommi
Ich habe einen S2500H Helligkeitssensor auf 868 MHz umgestellt. Dieser wird auch mit dem CUNO empfangen und landet im CUL_RegVar-Skript. Jetzt wollte ich dort noch den Part zum Verarbeiten der Nachrichten einbauen, komme jedoch nicht so ganz mit der Reihenfolge der Bytes klar. Auf der Webseite von dc3yc (weiß nicht ob man hier Links posten darf) stehen ja die einzelnen Protokolle, jedoch kann hier etwas nicht ganz passen, denn im CUL_RegVar-Skript wird die Temperatur z.B. aus $a[6].$a[3].".".$a[4] ermittelt. Diese Reihenfolge bekomme ich nicht mit den Angaben bei der Protokollauflistung zusammen.
Die Daten vom Helligkeitssensor wären z.B. K7507080006A, K75870000064
Wo ist hier mein Denkfehler - bzw. wie müsste ich die Daten in der Reihenfolge abarbeiten?
Grüße,
Martin
PS: Die CUNO-Anbindung an sich ist super praktisch, damit brauche ich meine xs1 nicht mehr…
Im culfw readme steht das so:
For S300TH:
KaaTTHTHH
Data must be read backwards
Das K ist Element $a[0].
Für den KS300 sieht das schon wieder anders aus
For KS300:
KFFTTTHWHWWRRFR
Data must be read backwards
Der S2500H ist im CUN Protokoll nicht beschrieben. Keine Ahnung, wie da die Bytes zusammengebaut werden. Eigentlich ist der Sensor im xx300-System je nicht definiert. Die letzten beiden Bytes im X21-Modus ist die Signalstärke. Mich irritiert etwas, das die Anzahl der Nutzbytes nach dem Kennbyte ungerade ist. Interessant wäre es, wenn man den richtigen Helligkeitswert zu Vergleich hätte.
HTH
Tommi
Hallo,
ich habe nen CUL USB Stick von Busware und ne EM1000 ca.8 Monate am laufen. Dies funktioniert soweit ganz gut.
Am Ablesetag meines Stromzählers, möchte ich gerne die EM1000 auf den Zähler des Stromzählers anpassen oder auf Null setzen.
Gibt es da eine Möglichkeit?
Habe dazu leider nichts im Netz gefunden
Danke
richimaint
Hallo zusammen,
ich möchte gerne insgesamt 6 Steckdosenadapter auswerten, gibt es da eine Möglichkeit für. Die IDs 5 und 6 wären bei mir doppelt aber die Adapter liefern ja andere Werte…könnte dies zur Unterscheidung genutzt werden ?
offiziell nicht. Aber das Script liegt ja im Quelltext vor, da kann jeder probieren. Man müßte den beiden zusätzlichen Geräten virtuell eine andere GeräteID geben und diese ID jedes Mal vor dem Abholen der VariablenIDs statt der originalen GeräteID setzen.
Tommi
mit der Version 0.11 des CUL_RegVar Scriptes können jetzt auch die günstigen FHT80 TFK standalone ohne gekoppelten FHT80B Thermostat angezeigt werden. Dafür wird eine eigene Kategorie angelegt. Die Beschreibung habe ich zusätzlich gemäß dem Feedback der letzten Wochen angepasst. Ich hoffe, damit sind die Zusammenhänge etwas klarer.
Tommi
eine neue Version des CUL_Event Scriptes beseitigt Probleme die durch eine unvollständige Initialisierung beim Systemstart auftreten konnten. Das Script wird jetzt zusätzlich als IPS-Startup-Script eingebunden und kann zur Not auch manuell gestartet werden
Tommi
Hallo tommi
Ich habe das Scriot mit einem Strom (01) und einem Gaszähler (09) am laufen. Das funktioniert prima.
Jetzt habe ich einen zusätzlichen GAssensor installiert. Dieser wird auch mit (0A) angelegt. Allerdings sind dort alle Werte 0 und er empfängt auch nichts auf dem Teil obwohl er sendet.
Könnte es sein, dass das Script probleme mit dem 0A (hex) anstelle 10(dez) beim entsprechendenSensor hat?
Hat das überhaupt schon mal jemand mit einem Sensor >09 getestet.
Die Adresse sollte eigentlich nicht Hex sein:
$type=substr($line,2,1);
$addr=substr($line,3,2);
...
} elseif($addr >= 9 && $addr <= 12) { // EMGZ: 0.01
Wenn doch wäre der Fix:
$addr=hexdec(substr($line,3,2));
Ich habe leider keinen Gaszähler. Deshalb kann ich auch nichts testen. Du müsstest mal den Debug Mode anwerfen und mir die Ausgabe schicken, was für diesen Sensor alles Hin und Her geht.
Tommi
Hallo Tommi
Ich habe mal ein kurzes Log und einen Screenshot wie der Sensor angelegt wird angehängt. Ich denke es kann nur hein Hex/Dez Problem sein weil es bis zum Sensor 09 (E0309xxx…)geht. Ab dem 2. Gassensor steht halt auch E030Axxx… im String.
CUL Cutter_log.txt (12.7 KB)
OK, wieder was gelernt. Probiere dann bitte mal den schon gestern angedachten Fix aus .Sollte in Zeile 112 sein.
Tommi
Hallo tommi
Ich habe den Fix mal rien kopiert. Allerdings wird das Ganze jetzt noch kurioser.
Jetzt wird der Sensor mit dem Namen „EM1010 Sensor 10“ angelegt und die werte da drin scheinen auch korrekt zu sein. Das problem besteht jetzt darin, dass jedes mal wenn ein Datenpaket kommt eine neuer Sensor mit dieser Bezeichnung angelegt wird. Ebenso wird bei jedem Datenpaket vom ersten Stromsensor „EM1010 Sensor 01“ nicht dieser aktualisiert sondern jeweils ein neuer Sensor mit der Bezeichnung „EM1010 Sensor 1“ (ohne die führende 0 bei der Sensornummer) angelegt. wenn ich das so weiterlaufen lasse, dann habe ich morgen hunderte neuer Variablen.
Ohne das Skript bisher so richtig verstanden zu haben, scheint es so als ob die Funktion get_ips_vars irgendwie mit dem was da jetzt geliefert wird Probleme hat und daher immer ein neuer Sensor angelegt wird. Könnte da was dran sein?
schade, wäre zu einfach gewesen.:rolleyes: Ich schaue mir das an.
Tommi