Windows GUI/Controller for MySensors

[tekka]

@Fredrik-Carlsson link works for me (https://goo.gl/48Yn6y)

[Fredrik Carlsson]

Yes I tried now again an now it works. Maybe something temporary with Dropbox yesterday

[cdr]

It is possible to burn the bootloader to an Arduino Uno right? (if not please skip below and I will rtfm some more)

Could anyone please explain me what I am doing wrong here? I use avrdudess (http://blog.zakkemble.co.uk/avrdudess-a-gui-for-avrdude/) to program the bootloader.hex (also tried the supplied method) but no dice;

Writing the bootloader seems to work;

Detected 1e950f = ATmega328P
MYSBootloader.hex: 2.002 / 32.768 Bytes (6,11%)
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 

avrdude.exe: set SCK frequency to 1500000 Hz
avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update.
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude.exe: Device signature = 0x1e950f
avrdude.exe: erasing chip
avrdude.exe: set SCK frequency to 1500000 Hz
avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update.
avrdude.exe: reading input file "C:\Users\codar\Desktop\MYSController_0_1_2_280\Bootloader\MYSBootloader.hex"
avrdude.exe: input file C:\Users\codar\Desktop\MYSController_0_1_2_280\Bootloader\MYSBootloader.hex auto detected as Intel Hex
avrdude.exe: writing flash (32722 bytes):

Writing | ################################################## | 100% 0.00s

avrdude.exe: 32722 bytes of flash written
avrdude.exe: verifying flash memory against C:\Users\codar\Desktop\MYSController_0_1_2_280\Bootloader\MYSBootloader.hex:
avrdude.exe: load data flash data from input file C:\Users\codar\Desktop\MYSController_0_1_2_280\Bootloader\MYSBootloader.hex:
avrdude.exe: input file C:\Users\codar\Desktop\MYSController_0_1_2_280\Bootloader\MYSBootloader.hex auto detected as Intel Hex
avrdude.exe: input file C:\Users\codar\Desktop\MYSController_0_1_2_280\Bootloader\MYSBootloader.hex contains 32722 bytes
avrdude.exe: reading on-chip flash data:

Reading | ################################################## | 100% 0.00s

avrdude.exe: verifying ...
avrdude.exe: 32722 bytes of flash verified

However tech life wouldn't be techlife without days of endless debugging

Setting the extended fuse fails verification

avrdude.exe: reading on-chip flash data:

Reading | ################################################## | 100% 0.00s

avrdude.exe: verifying ...
avrdude.exe: 32722 bytes of flash verified
avrdude.exe: reading input file "0xF7"
avrdude.exe: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude.exe: 1 bytes of lfuse written
avrdude.exe: verifying lfuse memory against 0xF7:
avrdude.exe: load data lfuse data from input file 0xF7:
avrdude.exe: input file 0xF7 contains 1 bytes
avrdude.exe: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.00s

avrdude.exe: verifying ...
avrdude.exe: 1 bytes of lfuse verified
avrdude.exe: reading input file "0xDA"
avrdude.exe: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude.exe: 1 bytes of hfuse written
avrdude.exe: verifying hfuse memory against 0xDA:
avrdude.exe: load data hfuse data from input file 0xDA:
avrdude.exe: input file 0xDA contains 1 bytes
avrdude.exe: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.00s

avrdude.exe: verifying ...
avrdude.exe: 1 bytes of hfuse verified
avrdude.exe: reading input file "0xFE"
avrdude.exe: writing efuse (1 bytes):

Writing |  ***failed;  
################################################## | 100% 0.03s

avrdude.exe: 1 bytes of efuse written
avrdude.exe: verifying efuse memory against 0xFE:
avrdude.exe: load data efuse data from input file 0xFE:
avrdude.exe: input file 0xFE contains 1 bytes
avrdude.exe: reading on-chip efuse data:

Reading | ################################################## | 100% 0.00s

avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x0000
             0x06 != 0xfe
avrdude.exe: verification error; content mismatch

avrdude.exe done.  Thank you.

This last error is giving me headaches, why the "first mismatch at byte 0x0000 0x06 != 0xfe" error?

Really hope someone can enlighten me...

[tekka]

@cdr the efuse only uses the lower 3 bits: with AVRDude set 0x06, with AVRStudio set 0xFE. You can verify this with the fuse calculator.

[Fabien]

I try to uplaod sketch via OTA but it doesn''t work.
I have sensebender with stock bootloader. Gateway is connect to an ODROID C1 with ser2net and i connect to ser2net. I can see all incoming traffic for my sensors.
I upload sensebender default sketch from dev branch using MySensors dev branch too.
I tell MYSController sensors is battery powered.
I try with the two provided example but nothing happen in log or anything else

[mvader]

@Fabien said:

I try to uplaod sketch via OTA but it doesn''t work.
I have sensebender with stock bootloader. Gateway is connect to an ODROID C1 with ser2net and i connect to ser2net. I can see all incoming traffic for my sensors.
I upload sensebender default sketch from dev branch using MySensors dev branch too.
I tell MYSController sensors is battery powered.
I try with the two provided example but nothing happen in log or anything else

check in the sensebender announcement thread. I had the same question. Hek responded with what needed to be done to make it work.
I didn't get a chance to try his solutions yet to see if it works. if you do, post and let us know.

edit: here
http://forum.mysensors.org/topic/1345/sensebender-micro/139

[Dirk_H]

@Fabien
I dont understand what you mean by "I told MysController" that the node is battery powered. It should find that out automatically I think. Anyway I'm pretty sure that I read somewhere that battery powered sensors cant be updated OTA. (If it relly is battery powered). I think I read a define somewhere that disables the firmware low level commands in the MySensors Library if the Node is battery powered.

[hek]

@Dirk_H said:

I think I read a define somewhere that disables the firmware low level commands in the MySensors Library if the Node is battery powered.

No there isn't. But battery powered sensors most likely sleep most of the time so they won't receive any update command. And a fw updates over-the-air would probably drain batteries pretty quick.

[cdr]

@tekka I feel really, really, REALLY stupid;

I changed the channel in the mysensors config.h to 77, this was the reason no node would ever show up since the default mysbootloader uses the default channel 76.

D'OH

Thanks for your patience and help, everything is working now and I'm really happy!
:+1:

[Omemanti]

Hi. I was wondering if someone could get the irrigation controller working with this program?
I'm new to this all, and so far this the easiest controller that I came across. ( got the gateway etc working with almost no effort)

[fitzpatrick]

Hi, nice work. Is there any chances that you add the possibility to log the nodes information to a mysql database ?

[5546dug]

Hi @tekka
I am having trouble understanding the error codes on this gui.

It is the solar mini weather stn on proto board and it is not working properly.

At this minute I see that the g/w code is telling me 4-4-5-0 ,there was a node 5 in my My Sensors package and it was configured as a repeater but it is not here as it connected laptop> usb port/cord> ftdi 3.3v> 3.3 v promini.
As the code cannot get to and from node 5 it is a down as a st=fail

Is there a why to change this in your program to allow continuing debugging my sketch?

Am I again missing something?
Thanks

[5546dug]

Sorry @tekka forgot the pic.

[tekka]

@5546dug the log looks like a sensor log, try connecting MYSController to the gateway...

[rvendrame]

Hello guys, I'm trying to burn the MYSBootloader.hex into some Pro minis (clones) here, however after burning it, they get somehow 'bricked' :

• I'm using my Uno "as ISP" on IDE 1.6.4
• I've followed the step-by-step tutorial posted above by @tekka
• My pro-minis are 5V, 16Mhz, external clock , 328p, supposedly a perfect match with 'boards.txt' info...
• "Burn bootloader" ends successful, with "Done burning boot loader" message.
• After that, the pro-mini pin 13 led flashes in a kind of random pattern, and it is not possible to upload any sketch, nor any kind of serial monitor on any speed.
• I can revert it, by selecting the standard 'Arduino Pro or Pro Mini' board , and burn boot loader again. It makes the pro-mini gets back to live, I can upload my sketches and serial monitor it.

So my questions:

• I don't have extra eprom connected --- Is it mandatory? I've read somewhere that it can be disabled, but can't find the instructions anymore...
• Fuse adjustments?
• What else can I do in order to troubleshooting it?

Thanks!

[scalz]

@rvendrame: it seems to be wrong fuses. MYSBootloader does not use extra eeprom. It's DualOptiboot which uses one. You need to set fuses. Then burn bootloader. For fuses you need to look in boards.txt . It should work. For setting fuses, I use usbasp. I never tried with uno.

[rvendrame]

@scalz, thanks for the reply. BTW, did you see this?

Well, with standard bootloader (working), my pro-minis have fuses as FF DA 05 (Low/High/Ext).

The MYSBootloader.hex boot loader (not working) is set in boards.txt with F7 DA 06.

I have played with all possible combinations (including changing values in boards.txt), no luck.

Maybe I have to compile my own version of MYSBootloader? Sorry, this is all new to me...

Thx again

[scalz]

@rvendrame: Hi I don't have a mac. But I use a similar tool for win (avrdudess). but your link seems ok.
You don't have to recompile MYSBootloader. MYSBootloader needs to match fuses. If not, it will blink like you have seen. Do you have an usbasp? very useful. So you need to burn fuses F7 DA 06. Did you try that? And then burn bootloader.
Be careful when burning fuses, don't try combination or you will semi-brick atmel chip (meaning you could not be able to reprogram it normal spi way). Never enable RSTDISBL and DWEN bits in fuse. You can see all of this here http://www.engbedded.com/fusecalc/ very useful too!

If in future you want to test new ota, I have made a small breadboard to test it. You can find it here : https://oshpark.com/profiles/scalz You will need to solder eeprom and atsha.

[rvendrame]

@scalz, yes I have tried to burn fuses F7 DA 06, and then MYSBootloader, no joy.

Maybe the main diference is the low fuse F7 ( = Ext.Clock full-swing Crystal ) , as my pro-minis run fine with FF ( = Ext. Crystal Osc 8.MHz ) ?

[rvendrame]

@scalz , one more thing: What speed did you set? The AVRFuses seems to work on at 19200 bps --- Could this be a problem?
And moreover --- You mentioned that extra eprom is not required --- But what about atsha? I don't have that either... (just pro-mini + radio ). Is it required for OTA?