CUNO stops sending signals after FW upgrade

[Guest]

Originally posted by: <email address deleted>

Hello,
 
Yesterday I've upgraded my CUNO v1 to firmware 1.46. No problems with this
and everything seemed to be working fine again. It shows that the firmware
is V1.46 and I'm receiving all activity from my FHT, HMS, etc, devices.
But it seems my CUNO doesn't send any signals anymore. I've tried FS20 and
FHT commands but my devices don't respond anymore.
What can be wrong? What can I do to troubleshoot this?
 
Thanks,

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> But it seems my CUNO doesn't send any signals anymore. I've tried FS20 and
> FHT commands but my devices don't respond anymore.
> What can be wrong? What can I do to troubleshoot this?

- you could try first to reset the parameters to "factory" defaults (e)
- does downgrading help?
- if you have another CUL/CUN, you could set it into debug mode (x67), and
  check what it receives

I do not have a CUNO (nor want one , so it might be that my advice is not
really helpful.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Ok, I tried the following:
1) reset to factory. -> no change
2) Reflashing the CUNO again with V1.46. Again no errors during 'make
usbprogram' and CUNO initializes good in FHEM. Receives everything but no
send.
3) Downgrade FW to 1.44 and all works again.
 
So thanks Rudolf, I've got a working system again but I sure would like to
upgrade to v1.46. Any suggestions?
 
 

Op dinsdag 9 oktober 2012 11:11:32 UTC+2 schreef Rudolf Koenig het volgende:

> > But it seems my CUNO doesn't send any signals anymore. I've tried FS20
> and
> > FHT commands but my devices don't respond anymore.
> > What can be wrong? What can I do to troubleshoot this?
>
> - you could try first to reset the parameters to "factory" defaults (e)
> - does downgrading help?
> - if you have another CUL/CUN, you could set it into debug mode (x67), and
>   check what it receives
>
> I do not have a CUNO (nor want one , so it might be that my advice is
> not
> really helpful.
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> So thanks Rudolf, I've got a working system again but I sure would like to
> upgrade to v1.46. Any suggestions?

- Try the head version, just to check if it is not already fixed
- Try 1.45 to narrow down the problem.
- If you know where it occured, try to make an svn diff of the 2 versions, and
  look for the bug, or ask here if you have some details.
- You may even try to check out revisions inbetween, and test them, so the
  diff is smaller. I never told, that it will be easy
 

Following is the list of changes since 1.44:
============
- CUNO2: added support for hardware patch - connecting Volkszaehler IR-head
- CUL: added RWE SH protocol receive
- CUL: added MORITZ protocol receive and send

Version 1.47
- all: CUL_FHTTK bugfix, don't filter out FHTTK's with a special adress
       (third byte is one of 4B, 53, 54, 69, 7D, 7E). Workaround: X61

Version 1.46 (2012-07-22)
- all: CUL_FHTTK is working again
- all: RFR silence while FHT is active changed
- all: RFR is compressing multiple FHT messages. Needs current fhem/CUL_RFR.pm

Version 1.45 (2012-07-11)
- CU*: added support for new multifrequency hardware detection
- CUNO2: bugfixed FHT8v timing
- CUL: VH returns the hardware version for CUL_V3 and CUL_V4.
- CSM: serial line overflow bug, TuxRadio2/board.h parameters changed
- all: Min length for FS20(4) and FHT(5) set, FHT8v removed from CUL_V2
- all: RFR won't send while FHT communication is active, T0200 added
============

I don't see any obvious candidate for your bug.  Are you connecting via USB or
LAN?  Are you using RFR? Is it a CUNO or CUNO2 (not that I would know the
difference


--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[tostmann]

                                                 

Am 09.10.2012 um 16:48 schrieb Alex van Hoboken:

> So thanks Rudolf, I've got a working system again but I sure would like to upgrade to v1.46. Any suggestions?

How does 1.45 perform? Does it work for you?

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

After first trying the v1.45 (worked fine) tried the latest release (v1.46
- 319) and this also worked fine.
So my problems are solved.
I don't see any difference between the 303 and 319 release that would
explain this phenomena I had.
 
Thanks for all the advice.
 
Op dinsdag 9 oktober 2012 18:44:53 UTC+2 schreef Rudolf Koenig het volgende:

> > So thanks Rudolf, I've got a working system again but I sure would like
> to
> > upgrade to v1.46. Any suggestions?
>
> - Try the head version, just to check if it is not already fixed
> - Try 1.45 to narrow down the problem.
> - If you know where it occured, try to make an svn diff of the 2 versions,
> and
>   look for the bug, or ask here if you have some details.
> - You may even try to check out revisions inbetween, and test them, so the
>   diff is smaller. I never told, that it will be easy
>  
>
> Following is the list of changes since 1.44:
> ============
> - CUNO2: added support for hardware patch - connecting Volkszaehler
> IR-head
> - CUL: added RWE SH protocol receive
> - CUL: added MORITZ protocol receive and send
>
> Version 1.47
> - all: CUL_FHTTK bugfix, don't filter out FHTTK's with a special adress
>        (third byte is one of 4B, 53, 54, 69, 7D, 7E). Workaround: X61
>
> Version 1.46 (2012-07-22)
> - all: CUL_FHTTK is working again
> - all: RFR silence while FHT is active changed
> - all: RFR is compressing multiple FHT messages. Needs current
> fhem/CUL_RFR.pm
>
> Version 1.45 (2012-07-11)
> - CU*: added support for new multifrequency hardware detection
> - CUNO2: bugfixed FHT8v timing
> - CUL: VH returns the hardware version for CUL_V3 and CUL_V4.
> - CSM: serial line overflow bug, TuxRadio2/board.h parameters changed
> - all: Min length for FS20(4) and FHT(5) set, FHT8v removed from CUL_V2
> - all: RFR won't send while FHT communication is active, T0200 added
> ============
>
> I don't see any obvious candidate for your bug.  Are you connecting via
> USB or
> LAN?  Are you using RFR? Is it a CUNO or CUNO2 (not that I would know the
> difference
>
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com