Integration Husquarna Automower G2 mit TASMOTA in FHEM

  • Hier geht es um eine Anbindung eines Husquarna G2 Modells an eine HA-Lösung, hier speziell FHEM.


    Durch den Einsatz eines ESP01 mit Tasmota ist es, mit etwas MQTT-Wissen, einfach möglich die Anbindung auch an andere HA-Systeme umzusetzen.


    Die hier vorgestellte Lösung ist bei mir an einem Husqvarna ACX 230 eingesetzt und sollte auch an allen anderen G2-Typen funktionieren.


    Viele Informationen zum Mower habe ich mir aus verschiedensten Foren zusammengetragen, besonders hilfreich war dieses hier aus dem HomeMatic-Forum (https://homematic-forum.de/forum/viewtopic.php?f=31&t=7295), wo auch viele Verweise auf andere Foren zu finden sind. In der PDF dort gleich am Anfang ist die Anschlussbelegung des Steckers zu finden. Vielen Dank an dieser Stelle an Mule! (Es könnte vielleicht Sinn machen den ESP01-Teil von hier auf diese Lösung zu adaptieren, ein einfaches „Durchreichen“ der Werte lässt sich einfach realisieren.)


    Auch das Forum https://www.roboternetz.de/com…rolux-und-Husqvarna/page9 war sehr hilfreich, hier habe ich Basis für die Excel-Tabelle her. Danke an Vogon!


    Und natürlich der Klassiker: http://automowerfans.free.fr, Merci beaucoup @poildecarotte!



    Zwei wesentliche Komponenten sind meine Basis:

    • die Einbindung über WLAN an MQTT
    • die Anbindung von MQTT an FHEM


    Einbindung Mower über WLAN und MQTT


    Die Einbindung des Mowers funktioniert über ein ESP01 Board, welches hardwareseitig an die Diagnoseschnittstelle des Mowers angeschlossen ist. Natürlich sind auch alle anderen, größeren Vertreter der ESP-Boards möglich.


    Ich habe eine kleine Lochrasterplatine im Bedienteil untergebracht, auf der der ESP und ein Stützkondensator mit ca. 100µF untergebracht sind. Da an der Diagnoseschnittstelle des Mowers alles über 3,3V läuft ist der Aufwand sehr übersichtlich. Stecker Pin 1->3,3V an ESP-3,3V, Stecker Pin2->Masse an ESP-Masse, Stecker Pin3-> Tx an ESP-Rx und Stecker Pin4(quadratisch)-> Rx an ESP-Tx.


    Seit vorsichtig, wenn hier dran baut! Messt zur Orientierung vorher am Stecker wo + und – ist. Zieht die Akkustecker beim Hantieren ab und prüft vor dem wieder reinstecken besser 3 Mal ob alles richtig ist. Und Bitte: alles auf eigene Gefahr!


    Ich habe selbst ein Motherboard für knapp 400,-€ auf dem Gewissen. Zugegebenermaßen ist das aber bei ersten Tests passiert, als der Mower auf dem Weg unter die Schrankwand den Kabelbaum der FTDI-Adapters vom Schreibtisch mit sich riss…




    Der Diagnosestecker ist schwer zu beschaffen und müsste von außen gesteckt sein. Es gibt je Model auch innen eine weitere Kontaktleiste die man nutzen könnte. Ich habe mich entschieden die Lochrasterplatine direkt an die Leitungen zum Stecker zulöten. Sollte der Mower zum Service müssen, ist es auf alle Fälle ratsam den ESP von der Platine zu ziehen!


    (siehe 2x Bild unten)


    Das ESP01 Board habe ich mit TASMOTA geflasht. Ich verwende immer die Script-Erweiterung von GEMU (Doku unter https://tasmota.github.io/docs/Scripting-Language/), die eine relativ einfache und geniale Programmierumgebung innerhalb TASMOTA zur Verfügung stellt. Mit den letzten Erweiterungen (Stand Juli 20) ist es möglich den Script-Speicher auf ca. 4000 Zeichen „aufzubohren“, was es ermöglichte die Statustexte alle auch hier mit unterzubringen. So könnte man das Ganze auch ohne weitere übergeordnete HA-Lösungen nutzen.



    Das Script für den ESP macht im Grunde nur folgendes:


    Innerhalb der TELEPERIOD werden 10 interessante Registerwerte (siehe Excel-Tabelle) zyklisch abgefragt, konvertiert und über den MQTT-Sensor-String an den MQTT-Server published.


    Aus den bekannten Statusmeldungen aus Register 01F1 und den Quittungen des Beschreibens von 812C wird zusätzlich ein „Substatus“ mit den folgenden 5 Zuständen gebildet: 1:charge 2:wait 3:error 4:move 5:mow. Die TELEPERIOD wird in Abhängigkeit dieser Substatis angepasst, für 1..3 beträgt sie 30 sec, ansonsten 10 sec. Das soll für zügige Updates in FEHM sorgen.


    Weiterhin wird ein MQTT Pfad „%topic%/cmnd/MOW“ subscribed, über den die Kommandos an den Mower gesendet werden können. Da es eigentlich nur darum geht ihn zur Arbeit oder wieder nach Hause zu schicken, reichen die zwei Kommandos „MODE_HOME“ und „MODE_AUTO“ aus. Eine 0 an /MOW stoppt, eine 1 startet den Mäher.


    Das Binary zum Flashen des EPS01 muss selbst und mit folgenden Compilerschaltern erstellt werden:



    #define EEP_SCRIPT_SIZE 4096 // mit Speichererweiterung

    #define USE_EEPROM

    #undef USE_RULES // Add support for rules (+8k code)

    #define USE_SCRIPT // Add support for script (+17k code)

    #define SUPPORT_MQTT_EVENT // enables support for subscribe unsubscribe

    #define USE_SCRIPT_WEB_DISPLAY

    #define USE_SCRIPT_STATUS

    #define USE_SCRIPT_JSON_EXPORT //enable >J section (publish JSON payload on TelePeriod)

    #define USE_SCRIPT_WEB_DISPLAY //enable >W section (modify web UI)

    #define SCRIPT_FULL_WEBPAGE //enable >w section (seperate full web page and webserver)



    Der Quelltext des Scriptes ist kommentiert. Ich empfehle den von GEMU entwickelten Editor zu nutzen, dieser entfernt die Kommentare beim Übertragen an den ESP und spart den knappen Platz. Der Workflow ist dabei so:

    • Bearbeiten des Quelltextes aus einen *.txt Datei (ein schönes Backup)
    • Senden per Tastendruck an den ESP

    Den Download für den Editor und seine Doku findet Ihr für Win und Mac, wenn Ihr in der Script-Doku (s.o.) nach „Optional external editor“ sucht. Ihr müsst dafür noch die IP-Adresse Eures ESP-Boards im Quelltext unter „IP=xxxx“ anpassen.


    Nehmt Ihr den Editor nicht, entfernt auf alle Fälle die Zeilen mit dem „SB=..“ und „IP=..“ und vielleicht die Kommentare.

    Das Script kommt in einem folgenden Post, es sind nur 10.000 Zeichen erlaubt..


    Habt Ihr das Script geladen lohnt sich ein Blick in die Tasmota-Konsole: dort gibt es hoffentlich das erste Erfolgserlebnis in Form einer funktionierenden Kommunikation.




    Anbindung über MQTT an FHEM


    Basis dafür ist das MQTT2_DEVICE. Ich persönlich nutze es im Zusammenhang mit einem MOSQUITTO-MQTT-Server.

    Hier die wichtigsten Aufrufe beim Anlegen des Devices:



    defmod <name> MQTT2_DEVICE

    attr <name>IODev <yourBroker>

    attr <name>icon scene_robo_lawnmower

    attr <name>readingList <your topic>/tele/LWT:.* LWT\

    <your topic>/tele/STATE:.* { json2nameValue($EVENT) }\

    <your topic>/tele/SENSOR:.* { json2nameValue($EVENT) }\

    <your topic>/tele/INFO.:.* { json2nameValue($EVENT) }\

    <your topic>/stat/RESULT:.* { json2nameValue($EVENT) }

    attr <name>room Garten

    attr <name>setList off:noArg <your topic>/cmnd/MOW 0\

    on:noArg <your topic>/cmnd/MOW 1

    attr <name> stateFormat sstate


    <your topic> ist dabei durch das eigene Topic zu ersetzen, <name> mit dem gewünschten Gerätenamen und <yourBroker> mit eurer MQTT Serverinstanz in FEHM.


    Nach erfolgreichem Laden wird man nach ein paar Sekunden die Readings sehen können.


    Das entscheidende Attribut für die Visualisierung ist das devStateIcon. Hierin befindet sich ein etwas größerer PERL-Codeblock, den ich zum besseren Verständnis hier extra aufführe. Einfach alles inklusive der beiden geschweiften Klammern kopieren und in das Attribut einfügen!

    Ich habe auch diesen Code in einem weiteren Post angefügt, wegen der Beschränkung auf 10.000 Zeichen..


    Am Ende sollte das dabei herauskommen:


    (siehe Bild unten)


    Man sieht die zwei (bunten) devStateIcons, die sich in Abhängigkeit des Batteriezustandes und des Substatuses ändern. Zur Batterie gibt es einen Ladezustand und die Temperatur. In der unteren Zeile wird der aktuelle Status mit seiner Nummer in Klammern angezeigt, beim Laden mit Ladestrom und Spannung. „On“ schickt den Mower zur Arbeit, „Off“ holt ihn zurück an die Station. Die Readings kann man ja bekanntermaßen aus anderen Elementen in FHEM abfragen und für die Steuerung anderer Komponenten (Beregnung usw.) auswerten.


    Zur Erklärung des Perl-Codes:


    Nach der Deklaration der Variablen werden verschiedene Werte aus den Readings errechnet. Im ersten given Element (was in anderen Sprachen so etwas wie ein Switch/case ist) wird das Icon für den Substatus festgelegt. Die if Anweisungen legen das Icon für den Batteriezustand fest. Das zweite given-Konstrukt bildet den Statustext in Abhängigkeit des Gerätestatus und ergänzt ggf. um Readingwerte (Strom/Spannung).

    Zum Schluss wir das Ganze formatiert und ausgegeben.



    Excel Tabelle:



    Ich füge noch eine Excel-Tabelle bei, die ich aus o.g. Forum bekommen und adaptiert habe.

    Im Reiter „Register“ sind alle Register aufgeführt. Ich hatte teilweise widersprüchliche Infos in verschiedenen Foren gefunden, diese findet man ab Spalte F. Da dies für mich nicht relevant war bin ich dem nicht nachgegangen. In der Spalte MQTT finden sich die zugeordneten Variablennamen für das Script.

    Im Reiter Kommando finden sich die Register für die Kommandos (stammt von Mule aus dem von Ihm geschriebenen Deamon). Ich verwende davon nur zwei.

    In Status findet man die bekannten Statis, meist auch aus Mule’s Daemon entnommen. Hier findet sich die Zuweisung zu den Sub-Statis, in H wird der PERL-Code für die when-Zweige zum rauskopieren gebildet.


    Ich habe gelegentlich Statis war genommen, die nicht in dieser Tabelle aufgeführt sind. Wenn jemand hierzu noch etwas beitragen kann: bitte gerne!



    Viel Spass!

    Ekkehard.

  • Hier das Script:

  • Und hier noch der PERL-Code:

  • Hallo Ekkehard,


    dein Projekt klingt sehr interessant. Bei mir grast ein 220AC.

    Die Umsetzung mit Tasmota reizt mich sehr, da ich immer wieder versucht habe hier eine saubere Lösung zu finden, die eine Verarbeitung der Befehle quasi "onBoard" macht und nicht nur über eine Serverlösung (IOBroker, FHEM, Symcon ...) oder dass der Mower quasi eine Bedienung über eine lokale Website ermöglicht.

    Ich hatte schon eine halbwegs funktionierende Verbindung mit einem WiFly RN-XV-Modul. Leider war dies nur eine Anbindung der seriellen Schnittstelle an mein SmartHome-System. Eine flächendeckendes WLan im Garten ist hierfür leider ein MUSS.


    Ein Mainboard habe ich dabei leider auch schon zerschossen, ohne den genauen Grund dafür zu kennen.


    Eine Frage habe ich noch. Hast du deinen Mower im Expert-Modus laufen oder normal?


    Schöne Grüße

    Ansgar

  • Hi, na dann nichts wie ran!

    Meiner läuft im Expert Modus, das wird sich hierauf aber nicht auswirken.

    Ich habe noch den Tip bekommen, dass die Lösung mit dem Script-Speicher, so wie ich sie verwendet habe, nicht sicher läuft. Bei mir gibts derzeit keine Probleme, aber ich werde sicher umstellen. Habe sowieso vor einen ESP32 einzusetzen, TASMOTA läuft ja mittlerweile auch schon darauf (wenn auch noch experimentell). Wenn Du also noch mehr Funktionen unterbringen willst, solltest Du das beachten. Wenn Du die Texte rauslassen kannst, dann sollte es noch so klappen.

    Das flächendeckende WLAN ist doch sowieso ein muss, die Liege mit dem iPad wandert doch immer der Sonne nach, oder? ;-). Für mich ist auch wichtig dass ich den Mäher von überall her nach Hause schicken kann, damit wenn er angekommen ist die Beregnung aus der Erde kommen kann.

    Also viel Spass! Drücke die Daumen!

  • Hi!


    Just found this forum and your post - I am looking to automate my Automower 220 using Home Assistant through an ESP module I will set up.


    Would you happen to have either code or an api description for talking to the serial interface of the 220? I tried searching everywhere but it must be a closely guarded secret by Husqvarna.


    I mainly need to know how to send/receive the commands you described above - ie do I need some special setup codes and such - a short code snippet would be great, but just command example would suffice. I would rather write the code myself in arduino than using scripts in tasmota since I prefer to minimize number of dependencies.


    best regards

    Jock

  • Hi Jock,


    indeed, it is a closely guarded secret, but the mowers are so old that a lot of enthusiasts figured it out. If you follow the links I've mentioned you'll find what you need (but a little German or French language skills might be helpful..). Also my Script code shows to you what you have to do. In principal: reading and writing registers. The hex-numbers of the registers you'll find in the attached spread sheet.


    Every telegram you've to send is 10 Bytes long:


    0F <regno> <value>


    0F is fix

    <regno> 4 Byte: register number in hex

    <value> 4 Byte: if you ask for a register set this to zero


    Do not write values in registers you're not aware what will happen!


    The mower answers with the same data, except <value> will present the value you've asked for (LS MS) or the commando gave in reversed order ( 00 03 ->03 00).


    Some examples out of my code:


    =#sd("0F812C0001") sends 0001 to register 812C (wich starts the mower)


    =#sd("0F01F100000F01EB00000F003800000F01EF0000") asks for the values in the 4 registers 01F1 01EB 0038 and 01EF.


    But why would you like to spend so much effort? Do you plan to connect your mower via wire to your HA? ;-)

    If not: use only the ESP-part of my approach and do what I did in FHEM in your HA. The Mower "speaks Mqtt" and all relevant Home-Automation system I know do this either. Publish commands to %topic%/cmnd/MOW and read in the %topic%/tele/sensor the JSON values of the registers you are interested in.


    Most of the solutions I've found during my search struggled with the issue to bring the serial data into an automation system. Often they use relatively expensive and complex serial to TCP/IP bridges or modified routers to this. I think the key feature of my approach is the use of a cheap ESP combined with a system like TASMOTA and more important MQTT.


    Hope this is helpful!

    Ekkehard

  • Thank you !!


    (mein deutsch is zu schlecht so ich muss english brauchen)


    I am actually planning on using a simple d1mini or likewise connected to WiFi and MQTT, I have a few left over (if the memory is enough) otherwise an esp32 or similar (have a few of those as well). the end goal is to use an esp32-cam so i can both connect to the mower, and upon errors see where it is, as well as using the recognition software - but that's for another day. That is why I am trying to use straight arduino code so I can expand it moving forward. I already have all the wifi and mqtt code ready, but instead of steering/reading IOT stuff like bulbs and switches in the house my plan was to send commands to the mower.


    as for the interface - do I need to connect the +/- on the serial interface to make the mower listen or is the actual serial interface powered by the connection? I noticed you used a capacitor to smooth surges btw gnd/plus and was wondering why connect it at all since the transmission distance is less than a couple of cm?


    so basically the interface method is to serially send four binary 0's followed by four 1's at 9600 baud to make the robot listen and then send the various commands in your excel sheet for getting/sending data? is there any timing outside of that - ie does it take time for the mower to execute before answering?


    cheers

    Jock

  • Hi Jock,

    seems you have the same plan regarding the ESP32: to use it with a cam and stream the video to an external system. I'd like to do this to a AI system to detect young hedgehogs. The mower handle them in not a very friendly kind.. what the reason is because I currently let the mower mow only over the day.


    I power the ESP via the + and - over the serial connection which provides 3.3V. The capacitor is because I read often that the 8286 need higher power for less time to drive the WIFI. I am not sure what the voltage regulator of the mower is able to drive and a additional capacitor cannot hurt.

    I am not really familiar withe the communication at the bit level. What I think is the mower detects the start of a command when 00001111 is sent. The size of a package is fix. I send more packages one after the other immediately. I did not measure how long it takes the mower answers, but I think is immediately. The answers are marked by the register values, might be they will be shifted time wise. In this post (https://www.roboternetz.de/com…rolux-und-Husqvarna/page8) you'll find some measurements "vogon" did.


    In the spread sheet you will not find any command to control the movement of a singe axis or so. But it must be possible. You'll find a tool at this site (http://automowerfans.free.fr/fans/pdc/tweakAMPC/index.html), which a lot of people are referring to. They do it. Btw, using this tool I've sent my mower on the journey to under the book shelf at my desk. With the effect that I had to buy a new motherboard. ;-).

    My plan is to sniff the communication.

    I would appreciate it to be in further contact, as long as my 230ACX is still on life ;-)

    rgds

  • once again, thanks!


    I really appreciate it!


    I will absolutely keep in touch - I will probably post everything on github in the end, so any cooperation is great. I also have an old 220AC so anything to give it a few more years of life is good. ;-)


    This is the module I am using ($7 so very cheap for good cam and an ESP module from banggood ) https://randomnerdtutorials.com/esp32-cam-ai-thinker-pinout/


    I think if you're pulling from the 220s battery you'll be fine for wifi (at least I hope so), I understand the capacitor now - I think there will be a lot of noise from the motors so a cap is probably good if you're powering the esp through it. worst case, I found some LiOn batteries construction for the mower at twice the Ah for the same size and weight

    (and cheaper too). I think I saw them commercially too. building a BMS and using LiON is above my skillset right now I think :-) so I hope the regular batterypack holds out.


    I read on one of the other forums that you have to set it into manual mode first and then you could actually control the wheel motors directly, Im not sure about the actual mower-motor though.


    regarding hedgehogs - great initiative! I plan to use the built-in AI stuff from Azure since they have good packages for vision from streams, but that is phase 3 - first phase is to get the mower talking, phase 2 is connecting HA and planning when not raining and such, phase 3 is altering the mowing runs using AI.


    look forward to talking soon!


    /Jock

  • I would have no concerns regarding the NiCd battery and spare parts are available. Upgrade to LiPo is a nice challenge technicalwhise, but it is too much effort for what benefit? My opinion.. The 230 has two packs in it, that means 4600 mAh, enough for a little more than 2 hours - even with the ESP on board.


    If you have some additional forums regarding the motor control- let me know!

    My next step is to build in the ESP32 with the cam (I know the ramdomnerd site and tested the software already), control the mower with it and stream the video. I plan to use the Tasmota for it.

    Have Success!

  • Hallo,


    ich habe mittlerweile meinen Wemos D1 mini (PRO) mit externer WiFi-Antenne im Automower AC220 in Betrieb genommen. Angeschlossen ist der Wemos an der internen Pin-Leiste. Im Netzt gibt es genügend Erläuterungen welcher PIN wo steht. In Tasmota habe ich den Serial-Log komlpett ausgeschalten.


    Das Gerät läuft seit gut 2 Wochen ohne Tadel. Anbindung an IP Symcon als Smarthome-Server über MQTT funktioniert mittlerweile auch zufriedenstellend.

    Ich hatte zunächst etwas Probleme mit den MQTT Befehlen aus Symcon. Ich hatte einige Tage damit verbracht Scripte in Symcon zu testen, damit die Kommunikation aus IP Symcon auch entsprechend funktioniert.


    Hier die grobe Implementierung in Symcon:



    Die Variable "Automower AutoHome" dient zur Rückmeldung an den Mower um die Befehle abzusetzen und reagiert auf eine Änderung der Variable "Auto_Home", die im Prinzip nur für die Anzeige im Webfront und das Schalten von dort benötigt wird. Es wird dann in den beiden Ereignissen entweder "AUTO" oder "HOME" an den Mower gesandt:



    Hier noch das PHP-Skript zum Auslesen und weiterverarbeiten der Sensorwerte und Statusmeldungen (ich habe mich hier bei diversen Quellen im IP-Symcon Forum bedient und tlw. ergänzt):


    Die jeweiligen Variablen sind entsprechend als Float, String oder Boolean anzulegen. Das sollte für Symcon Nutzer selbstredend sein


    Grüße

    Ansgar

  • Hey Ansgar75,

    cool! Freut mich dass es klappt. Bei mir ist das Thema mit den 4000 Zeichen Scriptspeicher in der älteren Version wirklich zum Problem geworden. Beim Compilieren also entweder Komprimierung für die 1Mbit devices (ca. 2500 Zeichen) oder für die 4Mbit (Wie bei Dir, dann 4096 Zeichen) die Lösung wie in der Script-Doku beschrieben verwenden. Das Script passt auch in die 1Mbit Lösung mit der Komprimierung.

    Hast Du irgendwelche nennenswerte Auswirkungen auf die Laufzeit feststellen können? Der 220 hat ja nur die Hälfte mAh als der 230..

    Viele Grüße!

  • Hey Ansgar75,

    cool! Freut mich dass es klappt. Bei mir ist das Thema mit den 4000 Zeichen Scriptspeicher in der älteren Version wirklich zum Problem geworden. Beim Compilieren also entweder Komprimierung für die 1Mbit devices (ca. 2500 Zeichen) oder für die 4Mbit (Wie bei Dir, dann 4096 Zeichen) die Lösung wie in der Script-Doku beschrieben verwenden. Das Script passt auch in die 1Mbit Lösung mit der Komprimierung.

    Hast Du irgendwelche nennenswerte Auswirkungen auf die Laufzeit feststellen können? Der 220 hat ja nur die Hälfte mAh als der 230..

    Viele Grüße!

    Hi Ekkehard,


    ich konnte bislang keine nennenswerten Laufzeiteinbußen bemerken. Ich denke, dass sich der "Konsum" des Wemos in Grenzen hält. Irgendwo hatte ich mal gelesen, dass dieser im Mittel so 90 mA zieht. Also wären das so rund 100 mAh wenn der Mäher eine Stunde on Tour ist. Bei 2200 mAh Akkukapazität gehen dann also höchstens rund 5% für den Wemos drauf (gerechnet mit 2000 mAh).


    Ich hatte im Frühjahr einen Akku mit größerer Kapazität (3000 mAh) verbaut. Änderung des Parameters #177 auf 3400 mAh. Damit läuft die Kiste jetzt nahezu 1,5h ohne Probleme.


    Grüße

    Ansgar