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

noansi · 09 November 2017, 07:22:01

Hallo Klaus,

danke für den Test. Er geht also in den Bootloader und flashen ist möglich.

Die Datenrate für das Flashen ist beim Nano hoch, aber das gibt der Bootloader vor. Die 57600 habe ich dem Makefile der Standard Firmware entnommen.
Kannst Du den Wert bestätigen, z.B. aus der Doku?
Läuft die Firmware denn? Oder zeigen sich Merkwürdigkeiten? Antwortet die Versionsabfrage?

ZitatWie kann ich denn die max. Stacknutzung testen?

Ohne Zugriff auf die Debugging Schnittstelle des Prozessors:
Wenn der verfügbare Stackspeicher nicht reicht, sollten Verhaltensfehler bis zum spontanen Neustart auftreten.
Die Uptime sollte der Laufzeit entsprechen.

Gruß, Ansgar.

klausw · 09 November 2017, 14:21:48

Hi Noansi,

Zitat von: noansi am 09 November 2017, 07:22:01
danke für den Test. Er geht also in den Bootloader und flashen ist möglich.

purer Eigennutz

Zitat von: noansi am 09 November 2017, 07:22:01
Die Datenrate für das Flashen ist beim Nano hoch, aber das gibt der Bootloader vor. Die 57600 habe ich dem Makefile der Standard Firmware entnommen.
Kannst Du den Wert bestätigen, z.B. aus der Doku?

Bisher habe ich immer mit 56k geflashed. Auch die Kommunikation mit FHEM läuft problemlos.
Schreiben lief auch fehlerfrei (was bei Flash Speicher länger dauert als das lesen)
Nur der verification error ist seltsam. Aber wie gesagt, das sind Nano Clone aus China. Wer weiß an welcher Stelle die Controller aus der Linie gefallen sind. Vielleicht ist es auch B-Ware.

Zitat von: noansi am 09 November 2017, 07:22:01
Läuft die Firmware denn? Oder zeigen sich Merkwürdigkeiten? Antwortet die Versionsabfrage?
Ohne Zugriff auf die Debugging Schnittstelle des Prozessors:
Wenn der verfügbare Stackspeicher nicht reicht, sollten Verhaltensfehler bis zum spontanen Neustart auftreten.
Die Uptime sollte der Laufzeit entsprechen.

Code Auswählen

version => VTS 0.18 CSM868
uptime => 0 14:39:39 (also seit dem flashen kein Neustart)

Ich habe nur 4 Komponenten dran (ist mein Testsystem)
Aber die sind erreichbar.

Nur dies scheint mir neu:

Code Auswählen

2017.11.09 13:42:30 2: TSCUL_ReceiveDelayed: culNano  C 00=07 01=2E 02=01 03=42 04=E9 05=CA 06=31 07=0C 08=45 09=00 0A=00 0B=06 0C=F3 0D=21 0E=65 0F=6A 10=C8 11=93 12=03 13=22 14=F8 15=34 16=07 17=3C 18=18 19=16 1A=6C 1B=43 1C=67 1D=91 1E=87 1F=6B 20=F8 21=56 22=10 23=AC 24=2C 25=14 26=11 27=41 28=00 29=59 2A=7F 2B=3E 2C=81 2D=35 2E=0B 2F=00 30=00 31=14 32=F3 33=00 34=AC 35=0D 36=00 37=00 38=30 39=CD 3A=00 3B=00 3C=00 3D=00

Aber seit Gestern habe ich auch testweise Rauchmelder dran, die vorher nicht gepairt waren.

Grüße
Klaus

noansi · 09 November 2017, 19:30:07

Hallo Klaus,

ZitatNur der verification error ist seltsam

Das hängt etwas davon ab, wie viel auf Deinem Testsystem sonst noch läuft. Es bedeutet nicht zwangsläufig, dass das Flashen schief gegangen ist. Wohler wäre mir aber auch, wenn das Verify Ergebnis positiv wäre.

Ich habe bei mir bei CUNO2 mit 38400 auch eine erfolgreiche Verifikation geschafft, mit Flashen über FHEM mit TSCULflash. Dabei wird FHEM eigentlich großenteils angehalten.
Flashe ich den nebenher, also nur mit avrdude und FHEM gleichzeitig laufend, dann bekomme ich auch meißtens Verfikationsfehler, wohl weil dann schlicht irgendwo ein Puffer überläuft (vermutlich der vom seriell nach USB Interface Chip auf dem nanoCUL) und somit Empfangsdaten verloren gehen, was dann zu einem "falschen Verifikationsfehler" führt.

ZitatNur dies scheint mir neu:

Wenn TSCUL längere Zeit (900s) nichts vom CUL empfängt, dann wird ein Register Read angestoßen. Das ist gedacht, um zu sehen, ob der cc1101 chip nicht im PLL-Lock State ist (war hier nicht der Fall) und wenn ja, ob daraus ein Grund abzulesen ist.
Wenn Du keine HM-Sensoren hast, die innerhalb dieses Intervalls Daten senden, die der nanoCUL empfangen kann, dann kann das aber natürlich auch so mal auftreten.

Wenn Du ordentlich testen willst, dann nutze bitte auch sign und aesCommReq.

Gruß, Ansgar.

klausw · 09 November 2017, 22:42:33

sign und aesCommReq muss ich später testen im produktiv System testen
habe hier nur 3 alte Rauchmelder die kein AES können und nen Dimmer

RaspiLED · 10 November 2017, 07:46:05

Hey Klausw,
man testet aber im Testsystem und nicht Produktiv

Gruß Arnd

Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

handy80 · 11 November 2017, 19:20:40

Hallo Ansgar,
vielen Dank erstmal, dass du dich der Firmware annimmst. Ich habe auch das Problem mit dem Klingelsensor.
Hab mir daher die neuste Version deiner FW als ZIP auf meinen RPI3 geladen, entpackt und wollte nun meinen USB CUL V3.4 (aufgedruckt auf dem Board des CULs) flashen (TSCULflash CUL1 TSCUL_V3) . Bekomme aber dabei in FHEM die Fehlermeldung:

dfu-programmer: no device present.

Eine Ahnung was ich überprüfen muss/kann?
DEF vom CUL ist bei mir: /dev/ttyACM0@38400 0000
Ich weiß aber nicht mehr aus welchem Blog ich die Definition geholt habe. Sie tut aber soweit bei mir mit culfw 1.66

Gruß Holger

klausw · 11 November 2017, 19:44:55

Zitat von: handy80 am 11 November 2017, 19:20:40
Eine Ahnung was ich überprüfen muss/kann?
DEF vom CUL ist bei mir: /dev/ttyACM0@38400 0000
Ich weiß aber nicht mehr aus welchem Blog ich die Definition geholt habe. Sie tut aber soweit bei mir mit culfw 1.66

versuche es mal mit 57600 Baud das funktionierte bei mir
die tty könnte passen, bei mehreren Arduinos am Pi ist es über /dev/serial/by-id/ aber sicherer

handy80 · 12 November 2017, 02:47:10

Hallo Klaus,
habe das fw-update hinbekommen. Keine Ahnung wie, nach dem 15 mal hat es geklappt.
ABER, warum bekomme ich nun bei allen HM Geräten beim ein oder aus schalten ein
"missing ACK"
Gruß Holger

noansi · 12 November 2017, 09:54:58

Hallo Holger,

zunächst, hast Du die Module aus dem FHEM Ordner der zip Datei in den FHEM Unterordner Deiner FHEM Installation kopiert? (vorher natürlich exisitierende gesichert)

Sofern Du nur einen CUL im System hast lautet die richtige TSCUL Definition Deines CUL V3 dann:

Code Auswählen

define CUL1 TSCUL /dev/ttyACM0@12000000 0000
da Du einen CUL mit direkter USB Anbindung hast.

@Klaus: 38400 ist für einen nanoCUL richtig, da der mit 38400 über einen USB nach seriell Baustein angebunden ist.

Dann muss es auch weiter passen, sprich die Attribute müssen passen:

Zitatattr CUL1 hmId F12345
attr CUL1 rfmode HomeMatic
attr CUL1 hmLanQlen 3_normal
attr CUL1 verbose 1
attr CUL1 room Receiver

Die "F12345" musst Du entsprechend Deiner bisher verwendeten hmId anpassen.

Dann FHEM Neustart, damit das auch übernommen wird.
Wenn AES zuvor nicht aktiv war, dann sollte es klappen, sofern die HM-Devices auch richtig und erfolgreich gepairt worden sind und natürlich in Funkreichweite sind.

Ansonsten:
Musst Du auch mehr Infos liefern, also List vom TSCUL und List vom device. Ggf. auch Mitschnitt der Kommunikation eines Schaltvorganges zu einem Problemdevice mit CUL1 auf verbose 4.

Hast Du zuvor AES verwendet? Sprich einen Schlüssel verteilt und sign in den HM-Devices auf 1 gesetzt?
Dann muss CUL1 den/die Schlüssel auch kennen...

Und die VCCU Nutzung ist nötig.

Gruß, Ansgar.

noansi · 12 November 2017, 11:45:30

Hallo Testwillige,

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

Diesmal 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

TSCULflash <nanodevicename> TSnanoCUL
bzw.

Code Auswählen

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 5 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 ungetesteten 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_19_FHEM_Modules_00_23.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUL_V3, TSCOC, TSCUNO2 und TSSCC. Jedoch nur mit einem AESCommReq tauglichen Bewegungsmelder für AES.

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

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

#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

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

Code Auswählen

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

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

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

attr HMdeviceName IOgrp VCCU
setzen, sondern

Code Auswählen

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.

Gruß, Ansgar.

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

EDIT1: 00_TSCUL.pm und 10_CUL_HM.pm aktualisert
EDIT2: 00_TSCUL.pm und 10_CUL_HM.pm aktualisert, roaming stabilisiert und "define %" wieder entfernt entspr. https://forum.fhem.de/index.php/topic,79858.0.html
EDIT3: 00_TSCUL.pm hmId Rückstellung bei virtuellen HM Sensoren

noansi · 12 November 2017, 15:04:34

Hallo Holger,

zum Flashproblem mit TSCULflash

Zitatdfu-programmer: no device present.

TSCULflash versucht den CUL mittels B01 Befehl in den Bootloader zu restarten.

Wenn das nicht sauber funktioniert, dann sieht dfu-programmer keinen Atmel Chip, den er flashen könnte.
Ob die CUL V1.66 Firmware dabei Probleme bereitet, kann ich nicht sagen.
Mit der TSCUL Firmware klappt es so zuverlässig auf meinem RasPi.

Dann gibt es alternativ noch die Möglichkeit, den CUL zuvor mittels "Programmiertaste gedrückt halten und in den USB Port einstecken" in den Bootloader zu starten.
Damit sollte es dann funktionieren.

Gruß, Ansgar.

Bytechanger · 16 November 2017, 06:31:01

Guten Morgen,

leider muss ich vermelden, dass in meiner Kombination (VCCU mit HMLAN und CUL V3) es weiterhin Probleme mit den HM-SEC-SC-2 gibt.
Bei eingeschaltetem aesCommReq wird nur das Öffnen fehlerfrei übertragen, beim schließen wird reproduzierbar:

aesCommToDev fail
trig_aes_vccu fail:40

angezeigt und damit der Statuswechsel nicht aktzeptiert!
Wenn ich Zeit habe, werde ich sniffingdaten liefern.
Welche werden benötigt?
Derzeit ist es so, dass die HM-SEC-SC-2 auf den HMLAN geschaltet sind.
IOgrp vccu:HMLAN1

Beim Umschalten auf CUL werden in beiden wechseln die o.g. Fehler angezeigt, aber der Statuswechsel akzeptiert?!
Allerdings hatte ich noch nicht die Zeit mal den HMLAN abzustecken.
Möglicherweise stören sich die Geräte in der Kombination.

Welche Logs soll ich senden, zur Analyse?

Greets

Byte

noansi · 16 November 2017, 23:18:50

Hallo Byte,

hast Du den letzten Stand TSCUL_fwcode_00_19_FHEM_Modules_00_20.zip getestet? Und hast Du auch die beigefügte 10_CUL_HM benutzt?

Ein HM-SEC-SC-2 ist bei mir im Zulauf. Damit werde ich dann mal testen, wie der sich so verhält.

Wie schaltest Du auf CUL um?

Gruß, Ansgar.

noansi · 17 November 2017, 21:24:29

Hallo Byte,

wie Du hier https://forum.fhem.de/index.php/topic,79145.msg717324.html#msg717324 lesen kannst, habe ich mit dem HM-SEC-SC-2 keine Probleme.

Hast Du mal mit dem aktuellesten Stand getestet?

Ansonsten Logs mit verbose 4 beim TSCUL und Rohdaten vom HMLAN.

Gruß, Ansgar.

klausw · 18 November 2017, 00:39:17

Hi Ansgar,

mir ist gerade die passende 10_CUL_HM.pm zur

Code Auswählen

00_TSCUL.pm 4 2016-11-05 19:41:39Z noansi
abhanden gekommen.
Da sich das System dummerweise in 400km Entfernung befindet möchte ich nur ungern den nanoCul mit der aktuellen Firmware flashen.
Könntest du die alte Version bitte nochmal online stellen?