Ich hab auch noch mal eine Frage zu dem sehr nützlichen NUT Modul.
Ist es so gewollt, dass der Socket ständig geschlossen und geöffnet wird?
Habe davon sehr viele Einträge im Log und in der Console sehe ich ständig das „!“ Zeichen.
ja, das ist so gewollt. Die Verbindung wird nur für die Zeit der Abfrage aktiviert, weil bei manchen Systemen die Anzahl der möglichen gleichzeitigen Verbindungen zum NUT Server limitiert ist. Das Abfrageintervall kann man im Konfigurationsdialog einstellen, falls das zu viel ist. Default sind 5min.
Tommi
Hallo ich wollte auch das Nut Modul benutzen , hab ich auch eingerichtet bekommen .
Modul läuft verbindung ist offen und im Debug Fenster (Siehe Bild) kommen auch Daten von der USV , jetzt meine Frage :
Wo finde ich die Variablen wieder Haken steht auf auto creation of new device aber nirgens sind die Variablen zu finden , oder muss ich die von Hand anlegen? und wenn wo?
Es wird normalerweise eine neue Kategorie „Nut Devices“, darunter die einzeln Devices(UPS) als Kategorie und darunter die Variablen angelegt. Die NUT Software muss das in der Splitter Konfiguration angegebene Feld mitliefern, damit die Geräte erkannt werden können. Default ist ups.serial. Wenn das nicht da ist, wird auch nichts angelegt. Am besten mal selbst nachschauen, welches Feld sich für das spezielle Modell eignet oder mir einmal den kompletten gelieferten Datensatz als Text schicken.
Tommi
ups.serial ist 0. Versuche bitte mal, statt ups.serial ups.model als Identifier zu nehmen. Doof wäre in dem Fall, wenn 2 identische USV am Server hängen.
Wenn das auch nicht hilft, schicke mir bitte ein komplettes Debug Log des Splitters von einer Abholung, ggfls mit den dazugehörigen Einträgen im IPS Log.
Hat alles nichts gebracht .Anbei der exportierte Log des Splitters.Die Werte die da drin stehen sind aber Aktuell.Ist schon komisch.
Eins hab ich noch vergessen zu schreiben Ich benutze die neuste Version (5).
dump.txt (42.4 KB)
Im normalen Log stand gar nichts???
Achso, 5.0 unterstütze ich noch nicht.
Hab mal über die alte Konsole das Meldungsfenster angehängt (soll man ja eigendlich nicht mehr nutzen) in der neuen Konsole hab ich das noch nicht gefunden.
Werde mal 4.4 wieder installieren um es zu testen.
Oh du hast recht in 4.4 funktionirt es alles super . Mal schauen ob ich dabei bleibe habe 5 eigendlich für die Google Home Sache installiert , wann könnte man den ungefähr bei Dir mit einem Update rechnen so das mann das Tool auch unter Version 5 nutzen kann?
Aber schon mal alle Achtung und Dank für die schnelle Hilfe im Vorraus an dich…
Ich hatte schon mal angefangen mit 5.0, aber es gab viele Fehler, wonach ich Stunden nach gesucht habe und es letztendlich an Beta-Fehlern oder noch nicht dokumentierten API Changes gelegen hat.
Ich wollte deshalb warten bis die Stable kommt und fange dann erst wieder an, die Module anzupassen.
Tommi
In diesem Fall liegt es weder am SDK noch an Fehlern in IPS.
Die Meldung sagt ja deutlich was los ist.
PHP 7 bringt Typisierung bei Parametern für Funktionen und verzeiht es einem nicht wenn man dann einen falschen Typ übergibt.
Bei PHP 5 war dies unproblematisch, wenn man ausversehen wie hier z.b. einfach ein Array anstatt eines erwarteten String übergibt.
Bei PHP 7 fliegt es einem dann mit Fehlermeldungen um die Ohren.
Michael
in diesem Fall liegt es weder am SDK noch an Fehlern in IPS.
Ist schon klar. Das ist aber auch nur eine Variante von Fehlern, die ich bekommen habe. Solange das SDK nicht vollständig,stabil und weitestgehend fehlerfrei ist, werde ich keine Zeit dafür investieren. Ich erinnere nur an die Typisierung für überlagerte Funktionen, die ich schon mal gemacht hatte, die dann aber nicht mehr/noch nicht mit dem SDK zusammen gepasst haben und ich sie wieder zurückbauen musste. Dafür sind mir meine paar Stunden Freizeit dann doch zu schade.
Tommi
Ja, die von Paresy auf GitHub bereitgestellt Datei für PHPStorm ist da missverständlich mit den Typen.
Es gibt diese einfach nicht im SDK.
Glaube auch kaum das die jemals kommen werden, da sonst das überschreiben von Methoden ja eben nicht mehr funktioniert.
Verstehe aber noch immer nicht wo das SDK fehlerhaft sein soll?
Fehler gab es, außer in neuen Features, keine. Verstehe darum deine Aussage nicht wirklich.
Das mit der wenigen Stunden Freizeit geht uns doch allen so 
Michael
Hallo,
ich bin Symcon Neuling und migriere gerade von FHEM. Ich habe einen Max Cube als Cuno geflasht. Kann ich diesen mit den MAX! Fensterkontakten mit dem Modul CUL anbinden?
Ich habe eine I/O Instanz und eine Splitter Instanz angelegt. Die Splitter Instanz zeigt auch die CUL Firmware Version V1.26.02 a-culfw an jedoch erscheinen die Fensterkontakte nirgends.
Habe ich etwas vergessen, oder geht das mit dem Modul gar nicht?
Viele Grüße
Carsten
Max und auch alle anderen „Sonderprotokolle“ wie Obis, Hoermann usw. sind nicht implementiert. Bei Max kommt noch dazu, das es eine andere Initialisieringssequenz für den Funkmodus braucht. Siehe culfw reference. Ich habe die Hardware nicht und kann es so auch nicht implementieren. Was implementiert ist, steht im Quelltext.
Tommi
Nach etwas längerer Pause gibt es die Module jetzt auch „offiziell“ für IPS5.0
Dazu bitte den Modulbranch auf 5.0 umstellen.
Tommi
Oh, vielen Dank!
Das rettet mir das Wochenende 
Hallo zusammen,
erstmal danke an alle die zu diesem Thema veröffentlichen.
Ich habe nun mehrere Wochen mit dem Thema CUL FS20 auf dem Raspi gelesen und gekämpft.
Was mich dabei schockiert hat, sind die tausend Infos alle irgend wie wahr aber keine komplett.
Klar hatte ich am Ende den nanoCUL aufgebaut, die Spannungsteiler integriert und die culfw kompiliert und geladen, aber auch alle Fehler die es gibt gehabt und gemacht.
Trotzdem, ich bin immer noch nicht sicher ob die culfw nun alles kann.
Schade, das es zu diesem neuen Modul nicht auch die dazu passende FW für die dort genutzten Devices gibt.
Nun meinen Fragen, ich nutze nanoCUL und culfw-1.67 auf IP-Symcon 5.0 Raspi3+ .
-
warum muss ich oftmals 2x klicken, um den ersten Schaltvorgange für eine FS20 Steckdose auszulösen, das nächste Schalten erfolgt dann sofort, auch muss man die Maustaste oft gefühlt länger drücken als beim Schalten über die FTZ1300 und IP-Symcon 3.4 Windows.
-
Wenn ich eine Steckdose per Webfront schalten bekommen habe, erfolgt die Anzeige der Umschaltung AN-AUS.
Wird die gleiche Steckdose von einem 2-fach Funkschalter oder FB geschaltet, erfolgt keine Anzeige der Umschaltung AN-AUS. Diese Funktion arbeitet aber bei der FHZ1300 fehlerfrei. Was mache ich falsch?
- Was könnte die Ursache dafür sein, dass meine CUL-KS300 Sensor 1 zu 50% bis zu 30 min später als mein WDE-1 und die WS300 ihre Daten aktualisiert?
In der gleichen Zeit werden aber die Daten des KS300 T/F Sensor 1 mehrmals aktualisiert.
Was kann oder muss ich an meinem System ändern?
Danke für die Hilfe
Tom
Ich versuche das mal aus Entwicklersicht zu beantworten.
Es gibt keine „die Wahrheit“ in einem OpenSource-Projekt. Jeder probiert und schreibt halt nur üb er den Teil, den ihn selbst betrifft. Wozu auch, die Zeit hat keiner in einem zudem so umfassenden Thema.
Ich teste den FS20-Teil meiner Module mit einem COC. Es ist mir nicht möglich, alle FW-Versionen zu Testen. Es macht auch keinen Sinn Firmware mit auszuliefern, da es einige verschiedene Varianten gibt. Idr steht im Modul, mit welcher Version ich es getestet habe. Es sollten aber alle Versionen kompatibel sein, die den für die genannte Version definierten Befehlssatz implementieren. Im Modul sind auch nicht alle Möglichkeiten der CULFW implementiert, schon weíl ich die Endgeräte gar nicht habe. Es kann aber jeder den Code erweitern/verbessern und mir einen PR schicken, damit ich das für die Allgemeinheit bereitstellen kann.
zu 1. Hier wäre es gut zu wissen, ob nach dem ersten Klick überhaupt ein Befehl rausgesendet wird (Debug Mode aktivieren)
zu 2. Die FS20 Technologie arbeitet ohne Rückkanal. IPS bekommt also nicht mit, ob sich der Schaltzustand wirklich geändert hat. Im Webwrontend setzt der Aktionhandler den Status selbst im Vertrauen, das alles geklappt hat. Wird von Aussen geschaltet z.B. mit der Fernbedienung bekommt IPS das höchstens durch ein Signal des Senders mit. Die FB ist aber oft sehr schwach.
zu 3. Der (selbstgebaute) NanoCUL ist HF seitig relativ störanfällig und braucht deshalb idR. ein relativ starkes Signal. Die FHZ macht das besser.
Besser machen kann man z.B den HF Teil: Externe Antenne, vom der CPU abgeschirmte Senderplatzierung, HF entkoppelte Stromversorgung, Aufstellung des CUL näher zu den Geräten. Noch besser ist gleich ein System mit Rückkanal zu nutzen.
HTH
Tommi