Hi Rudi,
ich hab jetzt schon ein paar Kandidaten gehabt, die mit der 1.67 Probleme mit dem IT-Protokoll hatten. Das letzte mal hier (https://forum.fhem.de/index.php/topic,82383.0.html).
Gefühlt sind das Probleme, die es mit der 1.66 nicht gab. Da ich ja weiß, dass IT nicht Deine Baustelle ist, wer kümmert sich um so was ? Wer hat bzgl. IT eine Änderung veranlasst ? Wenn die anderen Threads mit ähnlichen Problemen hilfreich sein sollten mein "Gefühl" zu konkretisieren, suche ich die noch raus ;D
Grüße Markus
ZitatDa ich ja weiß, dass IT nicht Deine Baustelle ist, wer kümmert sich um so was ?
Gefuehlt keiner.
ZitatWer hat bzgl. IT eine Änderung veranlasst ?
Laut "svn log culfw/clib/intertechno.c" sind das die letzten drei Aenderungen:
r538 | rudolfkoenig | 2015-12-20 10:33:02 +0100 (Sun, 20 Dec 2015) | 2 lines
intertechno patch: modify interval (Forum #45449)
r495 | rudolfkoenig | 2015-02-08 19:12:19 +0100 (Sun, 08 Feb 2015) | 2 lines
IT changes from Bjoern
r349 | mgehre | 2013-02-06 01:29:54 +0100 (Wed, 06 Feb 2013) | 1 line
MAX: reset moritz_on when initializing CUL
d.h. die letzten zwei Patches kamen von Bjoern, und die Letzte Aenderung war vor 1.66.
Laut CHANGED gab es fuer 1.67 ein "Fix the 433 PIN-check for "non-stdard" devices.", laut SVN-Log wg. Anfrage im Forum #65649
Zitat
Zitat
Da ich ja weiß, dass IT nicht Deine Baustelle ist, wer kümmert sich um so was ?
Gefuehlt keiner.
Hatte ich mir fast gedacht.
Danke für die Infos. Ich guck mal, wenn Zeit ist, wo da der Hund begraben sein könnte. Ich hab mich bisher noch nie mit der culfw, wohl aber intensiver mit der aculfw auseinandergesetzt. Es dürfte meines Erachtens zumindest nicht sein, dass Änderungen über andere als den maintainer des IT_Moduls einfließen. Oder anders ausgedrückt: Die Entwicklung zu IT findet ja maßgeblich über die aculfw und das IT_Modul statt. Irgendwann oder bei Abhängigkeiten zw. firmware u. Modul müssen Änderungen in der culfw nachgezogen werden, damit die Stände nicht auseinanderlaufen.