Controlling Automower

In short words I can't send any "serial" code without the bridge sketch. As far as I understand I can't use USB and Pin0/Pin1 anyway.

I understand that in the final application you have to use the WiFi for the communication. But I would try to communicate with the mower over simple serial communication first and when this works advance to the WiFi connection.

Why can't you use USB? You cannot use the hardware serial interface and the Bridge class at the same time, that's correct.

To be prepared for the WiFi usage later, you can start using the AltSoftSerial library (AltSoftSerial Library, for an extra serial port) to get a software emulation of a serial interface and one that is not blocking the complete Arduino. The pins are fixed to 13 and 5. You'll loose your LED but you can use any other pin to light an LED.

(deleted)

Maybe I don't understand some restrictions from the bridge sketch and serial over Pin1/Pin0:

The hardware serial interface is used to communicate between the two processors the Yun has, on the AVR-side (the Arduino sketch) the Bridge class is responsible for this.

How did you connect the mower to the Arduino? Please don't post the same pictures again, I want to see how you did it.

(deleted)

serial (HV) connected to 1 and 0 on the Arduino

This probably won't work because the hardware serial interface (which is on pin 0 and 1) is used for inter-processor communication on the Yun. If you have pins 5 and 13 in the Yun unconnected, use the AltSoftSerial library (AltSoftSerial Library, for an extra serial port) to get a software emulated serial interface.

power connected to 5V and GND

Your schematics say 3V3 and not 5V for the mower.

How do the wires connect to the mower?

(deleted)

(deleted)

mySerial.read(statusAutomower, 5);

There is no read() method that takes two arguments. This won't work.

Why don't you use AltSoftSerial but SoftwareSerial? The later will make you much more trouble because it blocks interrupts during every transfer and consumes all processing power available. So you might have to slow down the controlling application on the PC to not overflow the incoming serial hardware doing the Bridge transfer. The SoftwareSerial will block interrupts for at least 1ms (1 byte) during which the Bridge interface might transfer up to 25 bytes, 24 of them might magically disappear because no interrupt handler is emptying the hardware register.

(deleted)

(deleted)

Automower.ino: In function 'void doCommand(YunClient)':
Automower:157: error: no matching function for call to 'AltSoftSerial::read(uint8_t [5])'
/Arduino/libraries/AltSoftSerial/AltSoftSerial.h:44: note: candidates are: virtual int AltSoftSerial::read()

Use your old readBytes method, as I already wrote, there is no read method that reads multiple bytes.

  1. Pin5 and Pin13 apply for the Yun as well? In that case I can't use the internal LED anymore?

Yes.

  1. commandAutomower is an array with 5 bytes (HEX). Will altSerial.write(commandAutomower, 5); send out these 5 bytes in order without any LF CR or something like this? Does write even work?

It will send these 5 bytes (bytes are not in hex although they may be printed in hex) over the emulated serial interface. Yes, write works.

  1. Will altSerial.read(statusAutomower); read only the next 5 bytes? What happens if there are only four or six?

It will do nothing except generating a compiler error. See above.

  1. If I wait 1000 ms before reading (to give the Automower time to respond), will it be buffered or is it better not to wait?

If wait means you're calling delay() it's always better not to do that if anything else should happen on your Arduino (as receiving characters from any interface). Although most of this stuff is handled in the background using interrupts, these handlers just copy the incoming stuff to buffers and these buffers may overrun. Try to always react on events and never wait for fixed times except you have no other option.

(deleted)

So with readBytes I can use two arguments?

Yes.

I think with available >= 5 it should limit it to 5 bytes already, right?

You don't need that because readBytes() already waits until either the number of bytes were received or a configurable timeout was reached.

But is there a timeout if the response isn't immediate?

If you use readBytes() there may be one. See Stream - Arduino Reference

Should I move the reading to the loop?

Please explain in more detail.

There won't be any data except after sending 5 bytes.

What does that mean?

(deleted)

(deleted)

(deleted)

I would start by returning the hex codes of the mower's answer to the Yun client:

for (uint8_t e = 0; e < 5; e++) {
  client.print(statusAutomower[e], HEX);
  client.print(" ");
}

Post that output.

The basic code you posted seems to do something different than your code, so at least that very short excerpt doesn't help a lot.

(deleted)

However after some time (typically hours) I get weird messages:

Sounds like you're running out of memory slowly. Get rid of the usage of the String class. Although the worst memory leaking bug was fixed in version 1.0.5 of the IDE it still makes excessive use of dynamic memory allocation which fragments the memory and at some point it cannot allocate enough memory. At that point things get weird and unpredictable. Convert the complete string handling to C strings (character arrays).

Also use the F() macro for all constant string calls to print() and println() methods.

How can I implement something that checks if the start bit is correct?

You can parse the message and react on each byte instead of reading 5 bytes and checking for complete combinations. Although if the mower is only sending data if you sent a command before, this shouldn't be necessary.

(deleted)