search

heliflieger / a-culfw

Alternative culfw
Other
126 stars 64 forks source link

Selfmade Cul freezing with blinking LED when sending ITv3 messages #23

Open Jarvid opened 5 years ago

Jarvid commented 5 years ago

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 commented 4 years ago

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:

bfb579bd4f6 654b5c020d

Some merge commits were contained, too, e.g. 33f3b39d06 284afe99b2

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 commented 3 years ago

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).