Selfmade Cul freezing with blinking LED when sending ITv3 messages

[Jarvid]

Hello,

just set up my first selfmade cul with the latest(1.26.0.4) aculfw on an arduino nano v3.0.
For some reason the device alyways entered some strange mode when sending commands to my inter techno plugs with the use of isxxxxxx.... My plugs did rarly receive the command and the led on the arduino was blinking in fast frequence after sending the command.

This is not happening with a-culfw V 1.25.01. Here the commands are received and my arduino is not entering that strange unsesponsive status.

[andim2]

Hi,

semi-related observation:
I am having rather sporadic lockups on my nanoCUL868 (1.26.00; used for HomeMatic), too (roughly every couple of weeks: fast LED blinking, reset button non-working, USB disconnect required). Might be an entirely unrelated lockup case, though.

Given your description I did a
git log -p 1.25.01..1.26.04
(side note: this range contains commits with some annoying CRLF <-> LF EOL changes causing SCM history disruption!)
and this turned up some potential candidates (in areas relevant to nanoCUL) upon Q&D review:

bfb579b
654b5c0

Some merge commits were contained, too, e.g.
33f3b39
284afe9

where I then did a
git diff 33f3b39d06~2..33f3b39d06
git diff 284afe99b2~2..284afe99b2
to get at actual changes there, too.
(BTW these commits look like they might contain relevant candidates, too)

All in all I would say that
in your regression issue case here you should try to provide more precise version info (read: try suitable interim firmware versions) in order to
be able to narrow it down more precisely when exactly your regression issue case got introduced.

HTH!

[andim2]

I have since found further CUL-lockup-related info (i.e., my case?), thus documented at
wiki.fhem.de CUL.
However in your case we're seemingly talking about a fully reproducible and clean regression case (lockup reliably occurring after ITv3 msg, i.e. a "simple" logic/handling bug within code), as opposed to random(?) Optiboot-bootloader-induced lockups.
Ought to keep this in mind (i.e., keeping the potentially very different lockup reasons/issues properly apart).