CUL/CUNO: Experiences and troubleshooting.

[jrkalf]

Recently a group of members bought a CUNO device or already have a CUL or CUN device. I want to use this topic as a troubleshooting area. I've already encountered my first snags. Reply and I'll keep a INDEX in this first post to link to all solutions.

• First FLASH! (no, not first post), and my CUNO isn't responding to any telnet or screen commands.
• CUNO firmware installation on Windows

[jrkalf]

This is for the linux users, as I've only done this under linux.

Just after having followed the initial information from the CULFW website. You'll be hitting groundzero, the culfw isn't responding properly to DHCP (in my case). It get's a DHCP lease 3 times for 1 minute and then simply vanishes off your internal network.

If you follow the README or the CULFW website, it'll state connect to the console via the usb port: "screen /dev/ttyACM0@38400" <-- your screen program will not like this and reject this. The correct syntax is "screen /dev/ttyACM0 38400" <-- see, skip the @.

Now you get a valid connection to the console and you can configure your cuno according the README file.

The commands in short:
Wim - MAC Address
Wid - DHCP enabled flag
Wia - IPV4 Address
Wig - IPV4 gateway
Win - IPV4 network mask
Wip - tcplink port
WiN - NTP sever
Wio - GMT offset
----------------

Enough lecture, what did you do and did it work?
I used the following commands and it worked properly after that. Remember, you're typing BLIND, you don't see anything you enter yourself. Local echo is turned off during your screen session.

I typed in: V (Show me your version CUNO!)
The CUNO returned: V 1.40 CUNO868

I typed in: Wid00 (turn off DHCP)
I typed in: Rid (Show me your DHCP setting state please)
The CUNO returned: 00

I typed in: Wid00 (turn off DHCP)
I typed in: Rid (Show me your DHCP setting state please)
The CUNO returned: 00

I typed in: Wia192.168.0.1 (This is your static ipaddress entry. Configure to your requirements.)
I typed in: Ria (Show me your ip-address please)
The CUNO returned: 192.168.0.1

I typed in: Wig192.168.0.254 (This is your static gateway)
I typed in: Rig (Show me your gateway please)
The CUNO returned: 192.168.0.254

I typed in: Win255.255.255.0 (This is your netmask.)
I typed in: Rig (Show me your netmask please)
The CUNO returned: 255.255.255.0

I typed in: WiN 192.168.0.254 (MIND THE CAPITAL N IN THIS CASE! set your NTP server)
I typed in: RiN (Show me your NTP server please)
The CUNO returned: 192.168.0.254

I typed in: Wio01 (Setting my offset to GMT+1)
I typed in: Rio (Show me your GMT offset please)
The CUNO returned: 01

I typed in: B (Reboot and activate your settings!)

After that it'll take a few seconds and you can ping and connect to your device via telnet.

[Alexvanhoboken]

It's not really documented but after reading the readme's and following all the links I finally succeeded in flashing my CUNO from my Windows XP laptop. Here's how I did it:

• First I've installed the WinAVR package, downloaded from http://sourceforge.net/projects/winavr/. In the package is the avrdude application needed to flash the CUNO. Beware avrdude is only for transfering files, not for compiling like make!
• Second I downloaded the firmware from the culfw site and unzipt it with 7-zip.
• Next I've connected the CUNO to my pc with the USB cable while pressing the micro-switch on the back of the CUNO. A new device appears in device manager called 'MCP2200'. Ignore/cancel all request for driver installations.
• Select the device in devicemanager and choose to install driver. Let the program look in the docs folder for the MCP2200.inf. After installation a new USB serial port is added to the ports section. Look it up and check wich portnumber it received (COMx)
• Then open a dos prompt and go to the .\devices\CUNO folder where we can find the CUNO.hex. Also have a look at the makefile in here because that tells us which flags and parameters we have to use for avrdude.
• avrdude -p atmega644p -c avr109 -P COM8 -b 38400 -U flash:w:CUNO.hex -v

One disappointment, when connecting to the device with hyperterminal (and in my case on COM8) and checking the version it returned V 1.39. I assume the precompiled CUNO.hex that's coming in the firmware package is still v1.39. So if someone could send me v1.40 I would be very happy

[jrkalf]

Alex,

I can provide that somewhere tomorrow after sports. Do you want a nightly cvs build or the release version of 1.40?

[Alexvanhoboken]

Ehh, both? Let's experiment a bit

[KidE]

So... Finally had some time yesterday and with a quick help of Jelle we had the CUNO up & Running in a matter of minutes.

We were supprised that the FHT devices were drawing a plot in a matter of seconds instead of minutes 1 up for the CUNO

Today i finalized my install of my ultra small house computer called the "Guruplug server Plus"



It's a very neat small device of "Globalscale" technologies http://www.globalscaletechnologies.com/ ... -plus.aspx which will do the trick or running FHEM and other services.

Next assignment will be to get the logfile buffer running on the CUNO so that no messages ill be missed anymore when FHEM is not available.


Greetz

[KidE]

Today (and yesterday) i found a strange fhenomenon to which nobody had an awnser.

After exactly 2 hours and 20 min everything seemed to stop working and FHEM was not recieving any info anymore from the CUNO. After digging into FHEM and (because after a restart everything was ok) without any luck i started with building a CVS dump for the CUNO firmware just to see that there was no issue with that.

Well this worked out great because after flashing the new build onto the firmware all problems see to fade away as "snow for the sun"

As snow for the sun = dutch expression meaning: all problems the problems you are experiencing go away in total and you end up with what you want.
I dont have a clue what snow and sun have to do with it but Hey............... its working.

so far the dutch lessons.

[wwolkers]

vanish into thin air would probably be the most correct english translation

[Alexvanhoboken]

Looks fantastic, such a small linux server. How does it perform so far? did you already test some of the frontends?
The Guruplug looks like a far better solution for running FHEM 7*24 than what I have now.

[KidE]

well to be honnest it's functioning very good and to give you a short impression

I'm running Debian 6 with:

FHEM 5.0
PGM3
fheME
Mysql

With all this running the load of the above just after a reboot looks like this:

Code: Select all

root@guruplug:~# w
 17:40:22 up 7 min,  2 users,  load average: 0.00, 0.06, 0.05
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
root     ttyS0                     17:33   21.00s  1.55s  1.28s -bash

I say a respectable 0.00 to 0.06 is way LESS than i expected.

Take a good look at the features between the "Server" and "Server plus"
I have the PLUS version with 2x Gbit eth, 2x USB2.0, bluetooth, WlanG, eSata + MicroSD

@166 euro it was a very good investment. Only you have to modify the cooling but that is childs play

[jrkalf]

Lately there's been some troublesome experiences by KidE and me (well, me far less problematic) that the CUNO device had to be rebooted once every so often in order to keep it functioning properly.

Currently you can download the CVS from culfw. It'll have version 1.42 and it seems to be functioning normally. I must add I haven't had any issues with it yet.

Jelle

[KidE]

The problems i HAD looked like major packet loss while pinging the CUNO:

>$ ping -c 20 192.168.10.2
> PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
> 64 bytes from 192.168.10.2: icmp_seq=17 ttl=64 time=1.45 ms
> 64 bytes from 192.168.10.2: icmp_seq=18 ttl=64 time=1.51 ms
> 64 bytes from 192.168.10.2: icmp_seq=19 ttl=64 time=1.51 ms
> 64 bytes from 192.168.10.2: icmp_seq=20 ttl=64 time=1.50 ms
>
> --- 192.168.10.2 ping statistics ---
> 20 packets transmitted, 4 received, 80% packet loss, time 19008ms
> rtt min/avg/max/mdev = 1.457/1.498/1.519/0.045 ms
>
> Major packet loss Here!!

Also i noticed that the CUNO suddenly disapeared from the network:
In the FHEM global logfile lines like:

> 2011.03.20 19:17:03 3: CUL opening CUNO1 device 192.168.10.2:2323
> 2011.03.20 19:17:06 3: Can't connect to 192.168.10.2 No route to host

were found multiple times a day.

I was running CVS firmware V1.40 and after flashing V1.42 all my problems are gone.
Previously i had to poweroff the CUNO and restart FHEM multiple times a day. These problems are finally history :thumb:

Mailing my findings to the developers i got the reply that there were no changes made to the core..... But something fixed the issues.