Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.43

[OiledAmoeba]

Hab noch unusedstack vergessen:

Code Auswählen Erweitern

TSCUL unusedstack => 313

[noansi]

Hallo Florian, hallo Klaus,

ok, nun denke ich, zu wissen, was passiert.

Das Öffnen der seriellen Schnittstelle toggelt wohl DTR auf dem nano, was einen Reset auslöst, vgl. Schaltplan.
Die wilden Zeichen kommen wohl daher, dass der nano im Bootloader auf 57600 gesetzt wird und damit was wildes bei der seriellen Schnittstelle ankommt, die auf 38400 (USB/seriell Interfacebaustein) eingestellt ist.

Damit werden meine Reset Detektionsmessages mit dem Abschluss des Reboot des nanos ausgelöst.
Beim Abfragen der möglichen Befehle kommt es dann zum Problem, da die Reset Detektionsmessages durch den Parser laufen und dort wieder eine Initialisierungssequenz anstoßen (die im Normalfall auch sinnvoll ist). Die läuft auch schön nach Log durch.
Im Anschluss kommt ein Timeout für die ursrüngliche Abfrage der möglichen Kommandos, da es einfach zu lange dauert, respektive die Antwort nicht kommt.
Das wird als "totes" device interpretiert und die Schnittstelle wird wieder geschlossen und erneut geöffnet, was den Teufelskreis wieder anstößt. Blöd.

Ich melde mich, wenn ich dazu eine Code Lösung habe. Leider habe ich kein Testdevice, bei dem dieser Fall auftritt.

Gruß, Ansgar.

[noansi]

Hallo Florian, hallo Klaus,

hier ein neuer Satz Module und Firmware.

Bitte gebt mir Bescheid, ob es damit auch wieder mit dem nano klappt.

Gruß, Ansgar.

[OiledAmoeba]

Hallo Ansgar,

Du hast Recht! Ich habe ein wenig gegoogelt und dabei kam raus, dass das ein gewünschtes Verhalten des Arduino als "Entwicklerboard" ist. Mir ist da noch das in die Finger gefallen:

Code Auswählen Erweitern

import os
import sys
import termios
import fcntl

        self.fd = sys.stdin.fileno()

        # Stop resetting the arduino on serial connect

        self.newattr = termios.tcgetattr(self.fd)
        self.newattr[2] = self.newattr[2] & ~termios.HUPCL
        termios.tcsetattr(self.fd, termios.TCSANOW, self.newattr)
Das soll den Neustart beim Connect verhindern. Sieht auf den ersten Blick nach ein paar Zeilen aus einem Sketch aus...  Da ich hier keine Entwicklungsumgebung für HomeBrew habe, kann ich da leider nicht näher prüfen.
Ich habe auch eine Codezeile für Perl gefunden, die softwaremäßig beim Zugriff das Verhalten unterbinden soll. Leider unterstützt freeBSD das scheinbar nicht

Code Auswählen Erweitern

  $po->dtr_active(0);


edit 03.38h: V0.20 läuft bei mir!

[noansi]

Hallo Florian,

V0.20 läuft bei mir!

Schön.  Ohne Modifikationen denke ich.

Wie ist der unusedstack Stand nach einiger Laufzeit?

Gruß, Ansgar.

[noansi]

Hallo Testwillige,

hier eine neue Version 0.20 der Timestamp Firmware und der dazu benötigten FHEM Module.

Diese Version sollte Initialisierungsprobleme bei nanoCUL und miniCUL, bedingt durch deren Reboot beim Öffnen der Schnittstelle, beheben.

Außerdem Verbesserungen bei der HM-Devicezuordnung mit mehreren HM IOs, insbesondere nach einem Neustart von FHEM.

Es ist eine Prüfung auf Stacküberlauf eingebaut. Am Anfang des heap werden zwei Byte mit einem Bitmuster beschrieben. Wird das verändert, dann ist der Speicher wahrscheinlich korrumpiert, was durch einen Stacküberlauf ausgelöst sein sollte. Sofern der CUL dann noch kann sendet er ein "C_M" an TSCUL, was zu einem entsprechenden Log Eintrag führt.
Damit kann man vorsichtig die Speichergrenzen ausloten. Ein langer Testzeitraum ist aber erforderlich, um einigermaßen sicher zu sein, dass der worst case auch mal durchlaufen worden ist.
Außerdem ist ein Kommando mU (je nach Firmware) eingebaut, mit dem man den vom Stack ungenutzen heap in etwa auslesen kann (auch als get unusedstack in TSCUL verfügbar). Auch hier gilt, nur nach langer Laufzeit einigermaßen sinnvoll. Es macht sicher keinen Sinn auf Grund des Wertes den Speicher bis auf das letzte Byte auszuquetschen, denn weiterhin hängt die Stacknutzung vom gewählten Protokoll und Einstellungen ab.

In TSCULflash ist der Versuch des Flashens auch von NanoCULs und MiniCULs ergänzt. Da ich es aber mangels Hardware nicht testen kann, bitte ich um Feedback, ob es funktioniert. Vor dem Flashen wird ein "B00" also Reset für die TSCUL Firmware an den nano/Mini geschickt, 1 Sekunde gewartet und dann versucht mit avrdude zu flashen. Wäre nett, wenn das mal jemand testen und Feedback geben könnte.
Also erst die Firmware in den FHEM/Firmware Ordner kopieren und dann in FHEM mit

Code Auswählen Erweitern

TSCULflash <nanodevicename> TSnanoCUL
bzw.

Code Auswählen Erweitern

TSCULflash <minidevicename> TSminiCUL
versuchen zu Flashen. Im Log sollte danach (dauert etwas) die avrdude Ausgabe zu finden sein.

AESCommReq wird. Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 6 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei der nanoCUL und miniCUL Version habe ich nur 3 Empfangspuffer vorgesehen, um den Restpeicher für den Stack zu erhalten. Vielleicht hat jemand die Möglichkeit, die max. Stacknutzung mal ausgiebig zu testen, damit der verbleibende Speicher optimal "ausgequetscht" werden kann???

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_20b_FHEM_Modules_00_25.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUL_V3, TSCOC, TSCUNO2 und TSSCC.

Die tsculfw Firmware kann für TSCUL_V3 und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.
TSCULflash ist erweitert auf COC, SCC, CCD, rpiaddon, CUNO2 und CUNO. Jedoch ist es nicht ganz so einfach zu handhaben, da zum einen teilweise die Taste zu drücken ist und bei Raspberry PI Modulen die Rechteproblematik für den Zugriff auf die IO-Pins überwunden werden muss. Tips dazu in der Command-Ref auch bei RPI_GPIO.
Bei einem Stapel aus SCC mit aufgesetztem COC, CCD oder (rpiaddon?) ist unbedingt beim SCC Flash darauf zu achten, die Taste am gewünschten Modul zu drücken. Sonst wird das oberste Nicht-SCC Modul mit der SCC Firmware geflashed.
Mit CUNO2 ist das flashen noch nicht getestet (nur über USB!). Wichtig, aber auch hier, die Taste zu drücken.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann TSCUL_V3.
Beispiel:

Code Auswählen Erweitern

TSCULflash MeinCulDevice TSCUL_V3

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:

Code Auswählen Erweitern

#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034

Ergänzender Hinweis zu USB CULs: Nach dem flashen von TSCUL kann es sein, dass das Betriebssystem TSCUL eine neue Schnittstelle zuweist und ggf. auch anderen USB devices. Auf Linux mit "dmesg" heraus zu lesen.
Auch beim Neustart des Systems kann sich die Reihenfolge ändern. Bei meinem Raspi sogar abhängig von der Startart Reboot oder Einschalten.
Für CULs mit nativer USB Schnittstelle (z.B. CUL V3.x oder CUN) kann die \Firmware\tsculfw-code-459-trunk_lufa_00_08\culfw\Devices\99-usb-serial.rules nach /etc/udev/rules.d/99-usb-serial.rules kopiert werden. Dann wird CUL stets der Schnittstelle /dev/CUL868_0 (oder /dev/CUL433_0 bei 433.9MHz Version) zugewiesen und er kann mit

Code Auswählen Erweitern

define CUL_868 TSCUL /dev/CUL868_0@12000000 1234
bzw.

Code Auswählen Erweitern

define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert werden und es gibt keine Probleme mit wechselnder Schnittstelle mehr.
Die Seriennummer kann beim Compilieren der Firmware festgelegt werden, so dass damit dann auch /dev/CUL868_1 etc. für mehrere gleiche CULs möglich sind.

Das geht leider nicht bei nicht nativen USB CULs wie z.B. nanoCUL oder CUNO2. Hier muss eine 99-usb-serial.rules nach den Daten in der dmesg Ausgabe erstellt oder modifiziert werden, um den gleichen Effekt zu erzielen, sofern der USB-Seriell Interfacebaustein eine eindeutige Seriennummer liefert.
Ansonsten kann es noch mit der USB-Schnittstelle probiert werden, an der CUL eingesteckt ist ("lsusb" Ausgabe), was an meinem RasPi aber nicht funktioniert hat, da dieser abhängig von Warmstart oder Kaltstart andere USB-Portnummern vergibt.

In der Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

00_TSCUL.pm         -> statt der 00_CUL.pm, aus CUL devices werden damit TSCUL devices in der fhem.cfg (händisch anzupassen)
DevIoTS.pm            -> verbesserte Version von DevIo.pm für die TS Module
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL IO-devices zu verwenden, aus UNIRoll wird dann UNIRoll_TS  in der fhem.cfg (händisch anzupassen)
13_TSKS300.pm     -> statt der 13_KS300.pm, mit TSCUL IO-devices zu verwenden, aus TSKS300 wird dann TSKS300  in der fhem.cfg (händisch anzupassen)
14_TSCUL_TX.pm    -> statt der 14_CUL_TX.pm, mit TSCUL IO-devices zu verwenden, aus CUL_TX wird dann TSCUL_TX  in der fhem.cfg (händisch anzupassen)
14_TSCUL_WS.pm   -> statt der 14_CUL_WS.pm, mit TSCUL IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  in der fhem.cfg (händisch anzupassen)
CalcUtil.pm               -> Hilfsrechenroutinen für Taupunkt und Windstärkeindex

Da diese Module ergänzt werden (müssen!), überleben sie auch ein Update von FHEM.

Außerdem:

10_CUL_HM.pm         -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Derzeit ist die Nutzung dieses Moduls zwingend erforderlich!!!
98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

Wie immer, vor Austausch und Veränderungen der Module und fhem.cfg, erst Backup dann Ändern!

Mit folgendem Eintrag (oder Ergänzung des attributs) in der fhem.cfg kann man das fhem Update am ungewollten Austausch der angepassten Module hindern:

Code Auswählen Erweitern

attr global exclude_from_update 10_CUL_HM.pm 00_TSCUL.pm 16_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 98_TSCULflash.pm

Hier https://forum.fhem.de/index.php/topic,24436.msg501057.html#msg501057 noch Rudolfs Tip zur Aktualisierung des Commandref  nach dem Kopieren/Austausch der Dateien so dass dann auch Doku zur Nutzung zu lesen ist.

Code Auswählen Erweitern

fhem> { `perl contrib/commandref_join.pl` }

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.16 ab. Eine ältere Version wird also nicht unterstützt, da sich diesmal auch wieder das Timestamp Protokoll (inkompatibel zum vorherigen Stand) geändert hat, so dass mit dem Austausch der FHEM Module auch ein Firmwareupdate des CUL devices erforderlich ist!

Noch ein Tip zur Haltbarkeit des CULs. Jedesmal, wenn einem HM-Device das IODev durch Roaming neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf

Code Auswählen Erweitern

attr HMdeviceName IOgrp VCCU
setzen, sondern

Code Auswählen Erweitern

attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Device
sofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.

Ergänzt ist auch noch ein set TX3Send.
Damit lassen sich TX3 Sensordatentelegramme auf 433er CULs versenden.
Beispiel:

Code Auswählen Erweitern


define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 TX3Send H:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." SID:23 U")}

define NF_HumOut notify Sen_Aussen:humidity.* {fhem("set TSCUL_WS433 TX3Send H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." SID:23 U")}


Gruß, Ansgar.

Vorherige Version: https://forum.fhem.de/index.php/topic,24436.msg714173.html#msg714173

EDIT: 00_TSCUL.pm nochmal etwas fehlerkorrigiert.

[noansi]

Hallo Zusammen,

mir sind noch 3 Fehler in der letzten Änderung von 00_TSCUL.pm aufgefallen. Bitte die aktuelle Version oben verwenden.

Gruß, Ansgar.

[OiledAmoeba]

Mit der Version von heute Nacht:

Code Auswählen Erweitern

TSCUL uptime => 0 14:50:10
TSCUL unusedstack => 311

Mir ist noch aufgefallen heute Nacht, dass er state overload nicht ändert, wenn cond zurück auf ok geht. Ich hatte eine Situation, da war credit10ms > 2000 und state war noch immer overload (auch nach über 1h).

Ach ja, mein kleines Rettungs-Notify ist abgeschaltet.

Gesendet von meinem SM-G900F mit Tapatalk

[noansi]

Hallo Florian,

Mit der Version von heute Nacht

Nimm bitte die letzte Version von Firmware und Modulen.

dass er state overload nicht ändert, wenn cond zurück auf ok geht

Soll nicht so sein.

Es gibt drei Möglichkeiten, die einen overload erzeugen.
Zum einen die credits.
Und zum anderen kein freier Sendepuffer oder AES-Puffer.

Sendest Du dauernd etwas?
Oder hast Du AES noch nicht sauber eingerichtet, so dass devices häufig versuchen erneut zu senden?
Oder läuft da noch ein getConfig im Hintergrund?

Gruß, Ansgar.

[noansi]

Hallo Florian,

dass er state overload nicht ändert, wenn cond zurück auf ok geht

Soll nicht nur so nicht sein, sondern kann nach Code eigentlich nicht. Nach Code sollte dann auf Initialized gewechselt werden
Nur wenn Du STATE statt state betrachtest. Vielleicht mal ein reload im Browser ausführen?

Gruß, Ansgar.

[pte]

Hallo Asanger,

ich teste seit Anfang August Deine TSCUL Software in meiner Installation. Diese besteht Homematic-seitig aus 2x HMLAN Konfigurationsadapter und einem über ser2net angebundenen CUL866 V3.4. Alle drei an eine VCCU gebunden.
Aktuell verwende ich noch Deinen Stand TSCUL_fwcode_00_19_FHEM_Modules_00_23.
Grundsätzlich hat sich die Stabilität des Homaticnetzes sehr verbessert, kaum resend oder gar error bei in Summe ca. 80 Homematic-Geräten.

Ich habe aber ein Problem mit einer (energiemessenden) Schaltsteckdose HM-ES-PMSw1-Pl-DN-R1. Geschaltet wird eine Warmwasserzirkulationspumpe, also eher geringe Leistung.
Es kommt immer wieder vor (anfänglich aller paar Wochen, aktuell fast täglich), dass das device sich nach einem Schaltvorgang regelrecht aufhängt und mit set_off oder set_on im state stehen bleibt, keine Befehle mehr annimmt und sich nicht einmal mehr am Harwaretaster der Schaltdose schalten lässt. Erst ein Neustart durch abziehen und anstecken hilft.
Ich habe das Gerät schon ausgetauscht, gleicher Effekt, also eher kein Exemplarfehler.

Nun zum Thema, warum ich meine Frage in diesem Thread stelle:

Deaktiviert eine attr TSCUL dummy 1 den CUL vollständig?
Wenn ja:
Dann ist der TSCUL nicht nämlich nicht schuld, denn das Problem trat auch in dieser Situation auf.
Dann gehört das ganze Thema wohl nicht hierher.

Wenn nicht:
Kann ein (fehlerhaftes) Homematic-Packet ein Gerät nach Deinen Erfahrungen derart abschießen?
Kann dies mit timing Problemen zwischen den HMLAN's und dem TSCUL zusammenhängen? Kann es zu Überlagerungen durch gleichzeitiges Senden der HMLAN und des CUL kommen oder wird dies durch die VCCU verhindert? Soweit ich es verstanden habe, senden die HMLAN selbständig ACK und wiederholen die zugehörigen Befehle.


Hast Du einen Vorschlag, wie ich dem Problem etwas näher kommen könnte?

[noansi]

Hallo pte,

und sich nicht einmal mehr am Harwaretaster der Schaltdose schalten lässt. Erst ein Neustart durch abziehen und anstecken hilft.

Geschaltet wird eine Warmwasserzirkulationspumpe, also eher geringe Leistung.

Also ein nicht ohmscher Verbraucher. Bei Schaltvorgängen kann das Spannungspitzen zur Folge haben. Diese könnten die Schaltdose unglücklich stören.
Um das als Problemursache auszuschließen könntest Du statt der Pumpe mal eine Glühbirne (rein ohmscher Verbraucher) schalten. Wenn es damit nicht auftritt, dann wärest Du der Ursache ein Stück näher gerückt.
Tritt es nur bei Funkschaltvorgängen auf oder auch beim Schalten mit dem Dosentaster?

dass das device sich nach einem Schaltvorgang regelrecht aufhängt und mit set_off oder set_on im state stehen bleibt

Hat es dann den Schaltvorgang auch schon ausgeführt? Sprich, meldet ihn dann nicht zurück?

Ich habe 4 HM-ES-PMSw1-Pl mit Firmware V2.5 und so ein Problem noch bei keiner feststellen können, schalte sie aber nicht häufig (2-mal am Tag). Und auch keine induktiven Verbraucher.
Die Firmware für beide Modelle ist aber zumindest unterschiedlich.

Deaktiviert eine attr TSCUL dummy 1 den CUL vollständig?

Seit AES und Auto-Ack in der Firmware nein. Denn wenn noch ein device dem CUL zugewiesen ist, dann steckt die Einstellung im EEPROM. D.h. er würde seine automatischen Antwortabläufe ggf. noch ausführen.
Sicher aus bedeutet CUL vom USB Port abziehen.

Kann ein (fehlerhaftes) Homematic-Packet ein Gerät nach Deinen Erfahrungen derart abschießen?

Sollte nicht, denn das sollte eine gut programmierte Firmware abfangen.
Ich kann jedoch von HM-WDS30-OT2-SM berichten, die nach einem getConfig nicht immer auch wieder schlafen gehen, wie sie sollten. Möglicherweise empfangen die dann schlicht das abschließende ACK nicht und bleiben einfach wach. Damit saugen die dann jedenfalls recht zügig die Batterie leer. Das hat aber wohl nichts mit Deinem Problem zu tun, ist aber ein Beispiel für ein Firmwareproblem und/oder Protokollumsetzungsproblem.

Hast den Firmwarestand 2.5 auf dem HM-ES-PMSw1-Pl-DN-R1?

Hast Du AES bei der Schaltdose aktiv? Wenn AES aktiv ist, dann deaktiviere es testweise oder aktiviere es, wenn es inaktiv ist. Damit änderst Du zumindest was am Protokollablauf und vielleicht hilft es, wenn einer der vorherigen Vorschläge nichts bringt.

Aktuell verwende ich noch Deinen Stand TSCUL_fwcode_00_19_FHEM_Modules_00_23.

Gibt es mehrfach Zuweisungen eines HM-devices zu mehreren IOs (get assignIDs)?
Ich kann nur mit CULs testen. HMLAN Nebenwirkungen kann ich nur versuchen zu vermeiden.

Gruß, Ansgar.

[noansi]

Hallo pte,

Kann dies mit timing Problemen zwischen den HMLAN's und dem TSCUL zusammenhängen?

Die sollten nicht miteinander reden. 

Kann es zu Überlagerungen durch gleichzeitiges Senden der HMLAN und des CUL kommen oder wird dies durch die VCCU verhindert?

Es wird über das jeweils zugewiesene IO mit den HM-Devices geredet. Überlagern sollte sich daher nichts.

Sollte dennoch HMLAN mal was senden, was tsculfw auch senden möchte und kann tsculfw das in der CCA Phase empfangen, dann wird das Senden dieser Nachricht seitens tsculfw seit VTS 0.16 abgebrochen.

Soweit ich es verstanden habe, senden die HMLAN selbständig ACK und wiederholen die zugehörigen Befehle.

tsculfw tut so was zunehmend auch seit VTS 0.14 zu zugewiesenen Devices. 
Mit der Zuweisung der HM-Devices zu den IOs wird auch den IOs mitgeteilt, ob sie "zuständig" sind und somit, ob sie automatisch antworten.
Nur wenn Doppelzuweisungen auftreten, würden zwei IOs einem Device antworten. Insbesondere bei AES geht das dann eher schief.

Nimm den letzten Stand, da habe ich noch etwas verbessert, um das insbesondere beim Wiederverbinden eines CUL zu verbessern.

Gruß, Ansgar.

[pte]

Hallo Asanger,
danke für die ausführlichen Ausführungen.
Test mit abgezogenen CUL habe ich schon probiert. Fehler tritt dennoch auf, also kein TSCUL Problem.
Die Dose hat den jeweils letzten Befehl noch ausgeführt, hängt also irgendwie beim ACK.
Ohmsche Last teste ich noch.
Ob das auch beim Schalten an der Dose passiert teste ich auch noch mal.


Gesendet von iPhone mit Tapatalk

[pte]

AES nutze ich hier nicht.


Gesendet von iPhone mit Tapatalk