FHEM crash on FHT80b-3 modules (re-syncing)

Begonnen von Guest, 16 Januar 2011, 13:44:32

Vorheriges Thema - Nächstes Thema

tostmann

                                                 

For programming a CUNO via USB the command is:

"make usbprogram"

Thank you!

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

Guest

Originally posted by: <email address deleted>

Dirk,

That's what I've tried in both the CUNO or the Bootloader directory.
Using the default settings as supplied by the version 1.40 package of
culfw
The previous response is what I get back from running the "make
usbprogram". The only thing I have to alter in the makefile is the
AVRDUDE port so it points to /dev/ttyACM0 instead of /dev/ttyUSB0.


Jelle

On 16 jan, 22:43, Dirk Tostmann wrote:
> For programming a CUNO via USB the command is:
>
> "make usbprogram"
>
> Thank you!

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

Guest

Originally posted by: <email address deleted>

To give you a hint of the output, I've just done again as you exactly
state. And to be precise I've done it in the CUNO directory not the
CUNO/Bootloader directory.

-------
root@eBuntu:~/culfw/culfw-1.40/Devices/CUNO# make usbprogram
Creating load file for Flash: CUNO.hex
avrdude -p atmega644p -P /dev/ttyACM0 -b 38400  -c avr109    -U
flash:w:CUNO.hex

Connecting to programmer: .............................
----------

I'm now on about 16 lines of dots and nothing is happening. How long
should this keep running? Previously it was done in under 30 seconds.


n.b. I know this is an aweful topic by now. I'm just trying to get my
cuno working and I'll run the commands when specified to try and get
it running. Perhaps on a small irc conversation? I could also give a
small bit of ssh access to the node connected to the device. Perhaps
it'll speed up debugging the issue at hand.


Jelle

On Jan 16, 10:46 pm, Jelle Kalf wrote:
> Dirk,
>
> That's what I've tried in both the CUNO or the Bootloader directory.
> Using the default settings as supplied by the version 1.40 package of
> culfw
> The previous response is what I get back from running the "make
> usbprogram". The only thing I have to alter in the makefile is the
> AVRDUDE port so it points to /dev/ttyACM0 instead of /dev/ttyUSB0.
>
> Jelle
>
> On 16 jan, 22:43, Dirk Tostmann wrote:
>
> > For programming a CUNO via USB the command is:
>
> > "make usbprogram"
>
> > Thank you!

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

Dr. Boris Neubert

                                             

Am 16.01.2011 23:02, schrieb Jelle Kalf:
> -------
> root@eBuntu:~/culfw/culfw-1.40/Devices/CUNO# make usbprogram
> Creating load file for Flash: CUNO.hex
> avrdude -p atmega644p -P /dev/ttyACM0 -b 38400  -c avr109    -U
> flash:w:CUNO.hex
>
> Connecting to programmer: .............................
> ----------
>  
Just to  make sure that we know what you do: do you use an AVR109 or
STK500v2 board for programming CUNO or is the device connected to the PC
via USB directly?

If you use a programmer like the STK500v2, it must be connected to a
serial port directly - USB-to-RS232 converters won't work.

If you do not use a programmer, the device must be programmed with the
dfu-programmer tool. I will tell you later how to do it if this is the case.

Regards,
Boris

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

Guest

Originally posted by: <email address deleted>

Thanks for your response Herr Neubert,

Also thanks to all others already involved in trying to revive the
CUNO.
From what I've googled so far it _should_ be nearly impossible to
brick the atmega644p, hence my hope that with some help we should be
able to revive the CUNO.

I don't have any programmer, just the CUNO with the supplied USB
cable.

Assumption on my part:
I can't flash the cuno.hex file onto the board anymore because I've
repeated the procedure of changing the clockspeed to often. As stated
by Herr Tostmann as well. So probably the answer is in fixing this
first?
Symptoms: I can go towards bootloader mode by pressing the back button
and attaching the USB cable into the pc. When I then "screen /dev/
ttyACM0 38400" to the device, I do get a connection. Except that when
I press S (like previously stated in the procedure) I get a "?"
returned instead of the word "AVRDUDE" which happened previously.

I hope this is of any help troubleshooting.

Kind regards,

Jelle Kalf

On 17 jan, 06:17, "Dr. Boris Neubert" wrote:
> Am 16.01.2011 23:02, schrieb Jelle Kalf:> -------
> > root@eBuntu:~/culfw/culfw-1.40/Devices/CUNO# make usbprogram
> > Creating load file for Flash: CUNO.hex
> > avrdude -p atmega644p -P /dev/ttyACM0 -b 38400  -c avr109    -U
> > flash:w:CUNO.hex
>
> > Connecting to programmer: .............................
> > ----------
>
> Just to  make sure that we know what you do: do you use an AVR109 or
> STK500v2 board for programming CUNO or is the device connected to the PC
> via USB directly?
>
> If you use a programmer like the STK500v2, it must be connected to a
> serial port directly - USB-to-RS232 converters won't work.
>
> If you do not use a programmer, the device must be programmed with the
> dfu-programmer tool. I will tell you later how to do it if this is the case.
>
> Regards,
> Boris

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

Oskar

                                                     

Am 17.01.2011 um 07:56 schrieb Jelle Kalf:
> and attaching the USB cable into the pc. When I then "screen /dev/
> ttyACM0 38400" to the device, I do get a connection. Except that when
> I press S (like previously stated in the procedure) I get a "?"
> returned instead of the word "AVRDUDE" which happened previously.

Looks like the baud rate is not set correctly.  with some luck, you can get a correct response by trying screen with other baudrates, like 19200, 9600, 57600, 1200, 2400, ...

In case the baudrate of the board is not matching any standard ones, this will get tricky.  Since the serial port might not have a dedicated oscillator, it might be coupled to the frequency you tried to correct in the first place.

Cheers
   Oskar

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.
--
fhem geht auch auf mac os x

tostmann

                                                 

The OSC calibration value is stored at last two addresses of the EEPROM. So erasing them it the solution. This can be done via the ISP port using any ISP programmer.

Or you re-flash the bootloader, which erases the chip completely .

You'll need an ISP programmer in any case - so it might be easier to sent it back four maintenance...

Am 17.01.2011 um 11:45 schrieb Jan-Hinrich Fessel:

> In case the baudrate of the board is not matching any standard ones, this will get tricky.  Since the serial port might not have a dedicated oscillator, it might be coupled to the frequency you tried to correct in the first place.

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

Guest

Originally posted by: <email address deleted>

Herr Tostmann,

I don't have any programmers except for the usb cable and the dfu-
programmer program. So sending it back in for maintenance is the only
option.
I've send you an e-mail via wiki and tiki at busware.de. Perhaps we
can continue the return for maintenance mail there.

Thanks everyone for helping, it's time to send the device back to the
creator as the enduser seems to have broken the device.

Kind regards,

Jelle Kalf
jelle at kalf dot org

On 17 jan, 12:08, Dirk Tostmann wrote:
> The OSC calibration value is stored at last two addresses of the EEPROM. So erasing them it the solution. This can be done via the ISP port using any ISP programmer.
>
> Or you re-flash the bootloader, which erases the chip completely .
>
> You'll need an ISP programmer in any case - so it might be easier to sent it back four maintenance...
>
> Am 17.01.2011 um 11:45 schrieb Jan-Hinrich Fessel:
>
> > In case the baudrate of the board is not matching any standard ones, this will get tricky.  Since the serial port might not have a dedicated oscillator, it might be coupled to the frequency you tried to correct in the first place.

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

Guest

Originally posted by: <email address deleted>

On 16 jan, 16:47, Rudolf Koenig wrote:
> I don't think this is a CUNO bug, it is either a fhem or a perl problem.
> The message T594A002C17 is completely normal, it should be converted to
>   synctime: 10
>
> Could you please modify 11_FHT.pm, and insert following line before line 417:
> Log 1, "VAL: $val";
>
> $val should be 17, and line 417 is
>     my $fv = sprintf("%d%%", int(100*$val/255+0.5));
> in the fhem 5.0 version of 11_FHT.pm. I see no reason (yet) why it aborts.

On 16 jan, 16:47, Rudolf Koenig wrote:
> > on the FHEM crash part, a kind friend remarked that fhem might crash
> > due to the fact that I don't have a powered on actuator attached to
> > the FHT device. Might this be an issue as well?
>
> 1. As the 8v does not report back (RX only), the FHT80b does not actually know
>    if there is an FHT8v or not. The FHT80b only might get confused, as the
>    temperature wont change according to the commands sent out :)
>
> 2. Fhem should not crash, no matter how confused an FHT80b is.

Hi Rudolf,

The CUNO part is being dealt with superbly by Dirk Tostmann.

But on the crashing part, I've managed to crash my FHEM with the use
of the FHZ now as well.
This time I've already patched the 11_FHT.pm file like you said
earlier in the message thread.

My logfile now shows me a message that the VAL: returned with me is 0
instead of 17. After that fhem crashes. with the same error as with
the cul. so it doesn't seem to be CUNO or fhz related, but more fhem
related.

Logfile extract:
----
2011.01.23 00:42:41 1: VAL: 0
Argument "\x{ff}\x{0}..." isn't numeric in division (/) at /usr/share/
fhem/FHEM/11_FHT.pm line 418.
Illegal division by zero at /usr/share/fhem/FHEM/11_FHT.pm line 418.
----


Kind regards,

Jelle

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

Guest

Originally posted by: <email address deleted>

Sorry, I should have added more of the logfile in there. I've turned
on the logfile in debug mode and the output of the last commands that
crashed FHEM are:

----------------
2011.01.23 00:53:54 4: FHZ/RAW: 810c (Unparsed: )
2011.01.23 00:53:54 4: FHZ/RAW: 047f0909a001160c0000aa00 (Unparsed:
810c)
2011.01.23 00:53:54 5: FHZ1000pc dispatch 810c047f0909a001160c0000aa00
2011.01.23 00:53:54 1: VAL: 0
Argument "\x{ff}\x{0}..." isn't numeric in division (/) at /usr/share/
fhem/FHEM/11_FHT.pm line 418.
Illegal division by zero at /usr/share/fhem/FHEM/11_FHT.pm line 418.
----------------

the error is on line 418 now ofcourse as the code on line 417 now
reads:
Log 1, "VAL: $val";


Jelle

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

rudolfkoenig

                                                   

> 2011.01.23 00:53:54 1: VAL: 0
> Argument "\x{ff}\x{0}..." isn't numeric in division (/) at /usr/share/
> fhem/FHEM/11_FHT.pm line 418.
> Illegal division by zero at /usr/share/fhem/FHEM/11_FHT.pm line 418.

Line 418:
  my $fv = sprintf("%d%%", int(100*$val/255+0.5));
If $val is 0, why should this give an illegal division by zero?

I did the following experiment:
fhem>  define x FHT 160c
fhem>  { FHT_Parse $defs{x}, "810c047f0909a001160c0000aa00" }

which resulted in an updated reading of x (see "list x"):
  2011-01-23 11:54:33   actuator        0%
without an illegal division message. Btw. an FHT actuator message with a valve
position of 0 is the most common message in the fhem world, so this line is one
of the most executed lines.

Theory: This is a problem with your perl version.

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

Guest

Originally posted by: <email address deleted>

On Sun, Jan 23, 2011 at 12:03 PM, Rudolf Koenig wrote:
> I did the following experiment:
> fhem>  define x FHT 160c
> fhem>  { FHT_Parse $defs{x}, "810c047f0909a001160c0000aa00" }
>
> which resulted in an updated reading of x (see "list x"):
>  2011-01-23 11:54:33   actuator        0%
> without an illegal division message. Btw. an FHT actuator message with a valve
> position of 0 is the most common message in the fhem world, so this line is one
> of the most executed lines.
>
> Theory: This is a problem with your perl version.
>

Your theory might be correct, yet I'm leaning towards a FHEM bug and
an end-user issue between keyboard and chair as well.

I've managed to fix my house issue with the crashing fhem and been
able to reproduce it. On request I can mail the fhem-2011-01.log file
for debugging purposes. I've let it run in debug mode all afternoon
while experimenting.

Here it goes: The problem was a changed FHZ FHTcode.

So while the FHT80b devices (4 units) where known in FHEM the FHTcode
of the device changed. The devices kept reporting to the FHEM server,
FHEM knew their hex codes were correct, but the FHZ1000pc couldn't
handle the messages from the FHT80b devices because they weren't
paired with it. This ended up in CRC messages and eventually on trying
to set a value towards the device and this leaded to a crash of FHEM.

If you want I can mail you the logfile if you're interested in
additional debugging.


Jelle

--
Living on Earth is expensive, but it does include a free trip around the sun.

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

rudolfkoenig

                                                   

> If you want I can mail you the logfile if you're interested in
> additional debugging.

Only if there is something different from what you told us above regarding line
418. Right now I am sticking to my theory.

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

Guest

Originally posted by: <email address deleted>

2011/1/23 Rudolf Koenig :
>> If you want I can mail you the logfile if you're interested in
>> additional debugging.
>
> Only if there is something different from what you told us above regarding line
> 418. Right now I am sticking to my theory.

My perl version is the vanilla kind delivered by Ubuntu Lucid Lynx.
Having discovered that little snag I'm upgrading Maverick Meerkat
right now. I'll report back on that.


Jelle

--
Living on Earth is expensive, but it does include a free trip around the sun.

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

Guest

Originally posted by: <email address deleted>

I cheated to get the bug fixed. I don't get any crash messages any more.

I upgraded from Ubuntu 10.04 to 10.10. And since I was in an upgrade
mode, I also upgraded fhem 0.5 to fhem CVS.
It fixed the problem and arises another problem.

The two devices I had paired before the upgrade are performing nicely.
The two devices I had paired after the upgrade (so 4 FHT80b's in
total) aren't working perfectly. To be exact:

Since this morning 09:24 I got the last temperature messages of the
last mentioned devices (in this case Parental room and Attic). And
while they did send out actuator messages frequently the first
temperature update came in at 13:44 this afternoon for both devices.
In case of the attic it didn't even send out actuator messages. The
range shouldn't be the issue, the device is only 3 meters away behind
a plaster wall.

The two devices paired before the upgrade (kids-room and playroom)
they were working perfectly the whole time. Sending out both actuator
and temperature messages.

Perhaps I should split this issue off into a new mail?

Jelle

On Sun, Jan 23, 2011 at 8:43 PM, Jelle Kalf wrote:
> 2011/1/23 Rudolf Koenig :
>>> If you want I can mail you the logfile if you're interested in
>>> additional debugging.
>>
>> Only if there is something different from what you told us above regarding line
>> 418. Right now I am sticking to my theory.
>
> My perl version is the vanilla kind delivered by Ubuntu Lucid Lynx.
> Having discovered that little snag I'm upgrading Maverick Meerkat
> right now. I'll report back on that.
>
>
> Jelle
>
> --
> Living on Earth is expensive, but it does include a free trip around the sun.
>



--
Living on Earth is expensive, but it does include a free trip around the sun.

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.