Beiträge von eth

Hi MS,

es wird wieder Frühling, man merkt es..

Meiner steht noch im Keller, aber mal so aus dem Kopf:

Bei mir starte und stoppe ich den Mower mit:

Tul/GT/R2D2/cmnd/MOW 0
Tul/GT/R2D2/cmnd/MOW 1

Wichtig ist dass die MQTT Einstellungen im Tasmota passen müssen, ich mache das bei mir anders als im Standart:

Topic: Tul/GT/R2D2 (wäre bei Dir automower/ac220)

full topic: %topic%/%prefix%/ (! bei mir anders, ist im Standart vertauscht!):

Dann sollte das klappen.

Am besten Du testest das erstmal mit einem MQTT-Tool wie z.B. dem MQTT Explorer (http://mqtt-explorer.com, mit dem habe ich auf dem Mac und Win die besten Erfahrungen gemacht). Damit schliesst Du den ioBroker aus, zu dem kann ich leider nix sagen.

Good Luck! Wenns nicht klappt melde Dich ruhig!

Ekkehard

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!

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!

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/community/thre…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

Hier noch das Script:

>D 35
IP=192.xx.xx.10
;IP=192.xx.xx.11
sync=/Sync

;to change: assign next controller in chain
nc="websend [192.xx.xx.11] script >"
;nc="websend [192.xx.xx.10] script >"
;/to change

S1=0
S2=0
S3=0
;stores irrigation time per time slice for 3 circuits in maximum
m:tab=0 3

;master and next -token, token counts timeslices with every controller down
mt=0
nt=0
;master command
mc=0
;running command
rc=0

;timer
t:v1=-1
t:v2=-1
;for 
t:v4=-1

df=0
ev=0
ch=0
cx=0
Px="x"
tp=0
Sy=0
Pt="xx"
Pn=0
dt=0

>B
SetOption64 1
;to change
irrigation time per time slice in seconds, -1 means on over the whole irrigation process -> useful for dripping hoses with less flow rate, 0 means no irrigation
tab[1]=300
tab[2]=300
tab[3]=300
;tab[3]=-1

;default count of time slices, irrigation time per circuit is (df/ amount of controllers) * tab[x] in seconds
df=10
;dripping time for separate dripping process
dt=3600
;/to change
=#aoff
rc=0
;all off
=#aoff

>S
if mqttc>0
{
;handles sync of status variables via MQTT
+>Subscribe Sy,sync
;master command for external control of process
+>Subscribe mc,%topic%/cmnd/mc
}

if upd[mc]>0
{
print invoke %mc%/%rc%
if mc>0
and mc<5
{
;if command is running stop all to reset chain
if rc>0
{
rc=0
;send to next controller
=>%nc% mc=0
} else {
;currently no command running
rc=mc
switch mc

case 1
;initiate complete irrigation process 
;starts dripping hoses
=#sd
mt=df
rc=2
=>%nc% mc=2

case 2
; starts only dripping hoses
=#sd
=>%nc% mc=2

case 3
;immediately stop
nt=0
mt=0
ch=0
v1=-1
;all off
=#aoff
=>%nc% mc=3

case 4
;starts dripping hoses for defined time 
v2=dt
=#sd
=>%nc% mc=4
ends
}
} else {
if rc>0
{
rc=0
=>%nc% mc=0
}
}
mc=0
if upd[mc]>1
{
;clear update
}

}
if upd[mt]>0
{
;new master token, resets internal process to start new processing
nt=mt
v1=0
ch=1
}

if mt>0
and nt==mt
;v1 is timer controlling irrigation channels
and v1==0
{
=#cc
if ch<4
{
if tab[ch]>0
{
;load time in timer and starts current channel
v1=tab[ch]
=#pon(ch)
}
} else {
nt=mt-1
if nt==0
;no following controller
{
;stop all
=#aoff
->%nc% mc=3
}
->%nc% mt=%nt%
}
ch+=1
}

if upsecs%4==0
{
;for debug purpose
;print rc %rc% mc %mc% mt %mt% nt %nt% ch %ch% 
}

if v2==0
;dripping process via mc=4
{
v2=-1
=#aoff
}

if v4==0
;switch power supply off
{
v4=-1
=>power4 0
}

if Sy==2
;publish all POWER states
{
for Pn 1 4 1
if pwr[Pn]==1
{
Pt="ON"
} else {
Pt="OFF"
}
+>Publish %topic%/stat/POWER%0Pn% %Pt%
next
+>Publish sync 1
}

#aoff
;switch all channels off
=>power1 0
=>power2 0
=>power3 0

#sd
;start driping hoses
for cx 1 3 1
if tab[cx]==-1
{
=#pon(cx)
}
next

#cc
;clear channel, switch all channels off except dripping hoses
for cx 1 3 1
if tab[cx]>0
{
=#poff(cx)
}
next

#pon(tp)
;power on
Px="POWER"+sb(s(tp) 0 1)
=>%Px% 1

#poff(tp)
;power off
Px="POWER"+sb(s(tp) 0 1)
=>%Px% 0

>F
;controls switch on of power supply
S1=pwr[1]
S2=pwr[2]
S3=pwr[3]
if 
chg[S1]>0
or
chg[S2]>0
or
chg[S3]>0
{
if
S1>0
or
S2>0
or
S3>0
{
v4=-1
=>power4 1
} else {
v4=5
}
}

>E
ev=Clock#Timer
switch ev
;initiate irrigation
case 1 mc=1
;initiate additional dripping
case 2 mc=4
;initiate stopping all actions
case 16 mc=3
ends

>J
,"mt":"%mt%","mc":"%mc%","nt":"%nt%"

Ausgangssituation:

In einem Garten sind mehrere Ventilboxen an räumlich verschiedenen Stellen angeordnet. Alle Boxen hängen an der gleichen Wasserquelle (in diesem Falle Brunnen mit Pumpe).

Es gibt zwei verschiedenen Arten der Anzapfungen zur Beregnung:

• Kreisläufe mit mehreren Versenkregnern (= sehr hohe Wasserentnahme)
• Tropfschläuche (= niedrige Wasserentnahme)

Ziel:

Die Steuerung soll sicherstellen, dass:

• Jeder Wasserkreislauf einzeln Ein/Aus geschaltet werden kann
• Ein kompletter Beregnungsablauf direkt aus der Steuerung kontrolliert wird
• Der Start über einen externen Befehl von z.B. über ein HA-System wie FHEM etc. erfolgen kann, oder aus der Steuerung selbst, wobei der Zeitpunkt so gewählt wird, das der Gesamtvorgang vor Sonnenaufgang abgeschlossen ist (die Böden sind zu dieser Zeit am kühlsten).
• Ein Beregnungsablauf umlaufend die einzelnen Versenkregnerkreisläufe immer nur ein kürzeres, definiertes Intervall betreibt. Die Gesamtberegnungsdauer eines Versenkregnerkreislaufes ergibt sich so aus der Summe der Einzelzeitscheiben. Die Einzelzeitscheiben können pro Kanal festgelegt werden, um unterschiedliche Flow-Raten ausgleichen zu können. Ziel ist es, eine Fläche nicht „zu fluten“ sondern dem Wasser die Zeit zu geben versickern zu können.
• Es darf immer nur ein Versenkregnerkreislauf zur gleichen Zeit aktiv sein (sonst würde es die Pumpe nicht schaffen)
• Tropfschlauchkreisläufe werden den gesamten Beregnungsablauf über eingeschaltet, damit sie auf eine ausreichende Bewässerungsmenge kommen. Das klappt natürlich nur, wenn diese nicht zu viel Wasservolumen/Zeit benötigen.
• Tropfschlauchkreisläufe sollen auch alle mit einem Kommando gestartet werden können, um eine zusätzliche Bewässerung zu einer Tageszeit möglich zu machen.
• Die für die Ansteuerung notwendigen Netzteile sind nach der Nutzung abzuschalten. Wir wollen Energie sparen

Im konkreten Anwendungsfall sind zwei 3-fach Ventilboxen der Marke Gardena mit den passenden 24V Ventilen im Einsatz. Andere sind natürlich auch denkbar.

Hardwarebasis sind mehrere Sonoff-4CH-PRO-Controller, pro Ventilbox jeweils einer in einem Schaltkasten zusammen mit einen 24V-DC/12W- Schaltnetzteil (die Ventile vertragen auch DC).

Der Sonoff stellt 4 potentialfreie Kontakte zur Verfügung. Einen wichtigen Tip: (der 4CHpro hat ja auch 433MHz an Bord) ich hatte am Anfang das Problem dass er scheinbar willkürlich eingeschaltet hat. Das liegt daran, das der 433MHz Chip offenbar sehr „lernwillig“ ist und auf einmal auf andere Funksignale reagiert. Ich hatte ihm nie welche beigebracht..

Ihr findet hier eine Lösung zu dem Thema, die ich Euch im Sinne des Familienfriedens dringend ans Herz legen würde! (https://github.com/arendst/Tasmota/issues/911)

Ich verwende als Software natürlich TASMOTA und immer mit der 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. Hierzu muss man sein TASMOTA aber selbst compilieren. In der Anleitung findet man die nötigen Hinweise.

Die Boxen selbst müssen natürlich nicht voll mit Ventilen bestückt sein. An jedem Sonoff ist der Kanal 4 dem 24V Netzteil zugeordnet, welches bedarfsweise zugeschaltet wird. Die Kanäle 1..3 sind für die jeweiligen Ventile vorgesehen.

In den einzelnen Sonoff’s ist prinzipiell der gleiche Script-Programmcode enthalten. Die Bausteine kommunizieren über WIFI auf der niedrigst möglichen „Protokoll-Stufe“ (gemeint ist websend ohne DNS). Jeder Baustein kennt die IP-Adresse seines Nachfolgers, der Letzte die des Ersten. So wird ein logischer Kreis aufgebaut. Das bedeutet aber auch: WIFI ist für alle Sonoff’s notwendig. Fällt es aus, geht es nicht, fällt es während einer Bewässerung aus wird die abschalten.

Die Befehle für Start und Stop übergibt man initial nur einem (beliebigen) Baustein in der Kette, sinnvollerweise sollte das immer derselbe sein. Den Rest regeln die Bausteine untereinander. Sobald man einen neuen Ablauf initiiert werden bestehende abgebrochen.

Den Code findet Ihr im nächsten Post. Er 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. Diese Code passt mit Kommentaren nicht mehr hinein. Der Workflow ist dabei so:

• Bearbeiten des Quelltextes aus einer *.txt Datei (ist auch ein schönes Backup)
• Senden per Tastendruck an den Sonoff

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.

Nutzt Ihr den Editor nicht löscht unbedingt die Zeile die mit IP= beginnt.

Um das Script auf den jeweiligen Baustein anzupassen müsst Ihr folgendes ändern:

• Im >D-Trigger in nc= die IP-Adresse des nächsten Bausteins der Kette eingeben, der Letzte bekommt wieder die vom Ersten
• Im >B-Trigger die Werte in tab[1..3] ändern: (1..3 entspricht dem Channel 1..3 des 4CHpro) ein -1 (minus 1!) als Wert bedeutet hier, es ist ein Tropfschlauchkreislauf angeschlossen, 0 bedeutet dass keine Bewässerung stattfindet, alle Werte >0 sind die Sekunden einer Zeitscheibe für den betreffenden Kreislauf.
• Im >B-Trigger df= auf die Anzahl der Durchläufe multipliziert mit der Anzahl der Bausteine setzten (Bsp.: 5 Durchläufe für 2 Bausteine df=10, für 3 Bausteine df=15; ein Kreislauf bewässert dann 5x dem Wert in seinem tab[])
• Im >B-Trigger dt= auf die Sekunden, wie lange ein separater Bewässerungsablauf für nur die Tropfschläuche dauern soll (3600 = 1h) setzen

Das Script subscribed auf %topic%/cmnd/mc eine Steuervariable mc und ist die Softwareschnittstelle nach aussen.

• Schreibt man hier (bei immer nur einem Baustein!) eine 1 hinein, startet das einen kompletten Bewässerungsablauf.
• Eine 3 ist ein Sofort-Stopp (z.B. die Schwiegermutter taucht unvermittelt im Garten auf..).
• Eine 4 startet alle Tropfschläuche für die in dt festgelegte Zeit.

0 und 2 sind nicht für die Nutzung von außen gedacht, 0 initialisiert die Kette neu und 2 schaltet alle Tropfschläuche ein (für immer, wenn sie nicht wieder ausgeschaltet werden!).

Um die Bewässerung ohne HA-System zu steuern können die TASMOTA- Zeitpläne genutzt werden. Unter „Einstellungen/ Zeitplan konfigurieren“ können ja bis zu 16 Zeitpunkte definiert werden. Hier werden nur 3 genutzt:

• Timer 1 für den Start einer kompletten Bewässerung
• Timer 2 für den Start einer zusätzlichen Tropfbewässerung
• Timer 16 für ein täglichen Stop zu einer festen Zeit

Das Kannbei Bedarf im >E-Trigger einfach erweitert werden.

Timer 1 kann man so z.B. auf „Sonnenaufgang“ – xx:xx stellen (beachte das Minus!). Für xx:xx gibt man dann die Gesamtlaufzeit in h:mm ein. So startet der Ablauf h:mm vor Sonnenaufgang. Wichtig hierfür: die richtigen Geo-Positionsdaten (damit der Sonnenaufgang berechtet werden kann, am besten mit reincompilieren) und die Häkchen „Zeitpläne aktiveren“, „Aktiv“ und „Wiederholen“ gesetzt und „Aktion“ auf „Regel“. Über die Wochentage unten setzt man die Tage. Für ein Beispiel siehe auch das Foto unten.

Timer 2 und 16 stellt man sinngemäß auf feste Zeiten.

Ich habe das Ganze 2x bei mir unter FHEM laufen, jedoch nutze ich die Zeitpläne nicht. Bei mir triggert eine Auswertung des Regens der kommenden 2 Tage über ProPlanta und in einem Fall noch zusätzlich der Regenfall des letzten Tages über einen Netatmo den Start per publish mc=1. Ich werte noch das Reading „nt“ (next token) aus, daran kann man ungefähr sehen wie weit die Beregnung ist (ich bekomme davon aber sowieso nichts mehr mit, wenn ich mir nich ein Telegramm schicken lassen würde.).

Das ist natürlich für jedes HA-System spezifisch aber überall per MqTT zu integrieren.

Das Subscribe auf „Sync“ nutze ich, um von extern ein Update der POWERx Werte erzwingen zu können, um den Zustand der Ventile zeitnah visualisieren zu können, was sonst nur aller teleperiod passiert.

Viel Spaß damit!

Ekkehard.

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

Hi Maurice,

das müsste dann ein T1 oder 2 oder 3 sein?

Ich hatte das gleiche Thema mit einem Sonoff 4CH. Weiss leider nicht wie der Tx aufgebaut ist, beim 4CH gibts einen Taster mit dem er die angelernten Geräte wieder vergisst. Um sicher zu gehen habe ich damals auf der Platine eine Verbindung gekappt. Hier findest Du einen Link ins Github zu dem Thema.

https://github.com/arendst/Tasmota/issues/911

Vielleicht hilft Dir das ja.

Viel Erfolg

Ekkehard

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!

Und hier noch der PERL-Code:

{
use v5.10;
my $st = 0;
my $bsp = 0.0;
my $pic = 'scene_robo_lawnmower@red';
my $picb = 'measure_battery_0@red';
my $RSt = -1;
my $stattxt ='unknown';
$st=ReadingsVal($name,"sstate",0);
$bsp=ReadingsVal($name,"batt_used",0)/ReadingsVal($name,"batt_capacity",0);
$RSt = ReadingsVal($name,"status",-1);
given($st)
{
when (1) {$pic='hue_filled_plug';}
when (2) {$pic='measure_battery_100@green';}
when (3) {$pic='scene_robo_lawnmower@red';}
when (4) {$pic='scene_robo_lawnmower@orange';}
when (5) {$pic='scene_robo_lawnmower@green';}
}
if ($bsp>=0.12) {$picb='measure_battery_25@red';}
if ($bsp>=0.37) {$picb='measure_battery_50@red';}
if ($bsp>=0.65) {$picb='measure_battery_75@red';}
if ($bsp==1) {$picb='measure_battery_100@green';}
given($RSt)
{
when (0) {$stattxt='Mode Manual quittiert';}
when (1) {$stattxt='Mode Auto quittiert';}
when (3) {$stattxt='Mode HOME quittiert';}
when (6) {$stattxt='Linker Radmotor blockiert';}
when (12) {$stattxt='Kein Schleifensignal';}
when (16) {$stattxt='Außerhalb';}
when (18) {$stattxt='Niedrige Batteriespannung';}
when (26) {$stattxt='Ladestation blockiert';}
when (34) {$stattxt='Mäher hochgehoben';}
when (52) {$stattxt='Kein Kontakt zur Ladestation';}
when (54) {$stattxt='Pin abgelaufen';}
when (1000) {$stattxt='aus LS ausfahren';}
when (1002) {$stattxt='Mähen';}
when (1006) {$stattxt='Mähwerk starten';}
when (1008) {$stattxt='Mähwerk gestartet';}
when (1012) {$stattxt='Signal starte Mähwerk';}
when (1014) {$stattxt=sprintf("Laden %.01fA, %.01fV, %dmin",ReadingsVal($name,"batt_current",0)/1000,ReadingsVal($name,"batt_voltage",0)/1000,ReadingsVal($name,"batt_charge_time",0));}
when (1016) {$stattxt='in LS wartend';}
when (1024) {$stattxt='aus LS einfahren';}
when (1036) {$stattxt='Viereckmodus';}
when (1038) {$stattxt='Festgefahren';}
when (1040) {$stattxt='Kollision';}
when (1042) {$stattxt='Suchen';}
when (1044) {$stattxt='Stop';}
when (1048) {$stattxt='Andocken';}
when (1050) {$stattxt='aus LS ausfahren';}
when (1052) {$stattxt='Fehler';}
when (1056) {$stattxt=' Wartet (Modus Manuell/Home)';}
when (1058) {$stattxt='Begrenzung folgen';}
when (1060) {$stattxt='N-Signal gefunden';}
when (1062) {$stattxt='Festgefahren';}
when (1064) {$stattxt='Suchen';}
when (1066) {$stattxt='Fernverfolgungsproblem';}
when (1070) {$stattxt='Suchschleife folgen';}
when (1072) {$stattxt='Schleife folgen';}
default {$stattxt='??? unbekannt ???';}
}
"<div>". sprintf(" (%d%, %d°C)",$bsp*100,ReadingsVal($name,"batt_temp",0)) . FW_makeImage("$picb") ." ". FW_makeImage("$pic") . "</br>" . sprintf(" (%d) ",$RSt) . sprintf($stattxt) . "</div>"
}

Hier das Script:

>D 45
SB=4096
IP=192.168.xxx.xxx
;input string via serialreceive
is=""
;send string
ss=""
;current command
ac=""
tt=""
MOW=0
lo=0
rt=0
;mqtt status values, see >J for description
mt=0
ak=0
ct=0
cb=0
st=0
s=6
bt=0
tc=0
uc=0
bv=0
nc=0

>B
;SetOption64 1
=>Baudrate 9600

>E
is=SerialReceived
;print is-> %is%
if sl(is)%10==0
;otherwhise there must be an communication error, if so discard packet
{
for lo 1 int(sl(is)/10) 1
;split packet in single register information and separate register in ac
ac=sb(is ((lo-1)*10)+2 4)
;convert hex return into value in rt
rt=hd(sb(is ((lo-1)*10)+8 2)+sb(is ((lo-1)*10)+6 2))
print lo %lo% ac %ac% rt %rt%
;assign to mqtt values
switch ac
case "01F1" 
st=rt
case "01EB" 
ak=rt
;this is signed integer
if rt>32767
{
ak=rt-65536
}
case "01EF" 
cb=rt
case "0038"
mt=rt
case "01EC" 
ct=rt
case "2EE0"
uc=rt
case "0233"
bt=rt
case "2EF4"
bv=rt
case "0234"
tc=rt
case "00B1"
nc=rt
case "812C"
;return of HOME and STOP cmd’s
st=rt

ends
next
}

>S
if mqttc>0
{
;for start/stop via MQTT
+>Subscribe MOW,%topic%/cmnd/MOW
}

if upd[MOW]>0
{
if MOW>0
{
print Start mowing
=#sd("0F812C0001")
tper=10
} else {
print Move Home
=#sd("0F812C0003")
tper=10
}
}

;ask every cycle for only 4 registers in maximum, because of limited size of string vars
;timing depends on teleperiode to reduce traffic

switch upsecs%tper
case tper-3
=#sd("0F01F100000F01EB00000F003800000F01EF0000")
case tper-2
=#sd("0F01EC00000F2EE000000F2EF400000F02330000")
case tper-1
=#sd("0F023400000F00B10000")
ends
;s stores aggretated substates 1:charge 2:wait 3:error 4:move 5:mow
s=3
switch st
case 0
=#pt("Mode Manual quittiert ")
s=4
case 1
;1..3 initiated by cmd 812C!
=#pt("Mode Auto quittiert")
s=4
case 3
=#pt("Mode HOME quittiert")
s=4
case 6
=#pt("Radmotor blockiert")
case 12
=#pt("Kein Schleifensig.")
case 16
=#pt("Außerhalb")
case 18
=#pt("Niedrige Batteriesp.")
case 26
=#pt("Ladestation block.")
case 34
=#pt("Mäher gehoben")
case 52
=#pt("Kein Kontakt zur LS")
case 54
=#pt("Pin abgelaufen")
case 1000
=#pt("aus LS fahren")
s=4
case 1002
=#pt("Mähen")
s=5
case 1006
=#pt("Mähwerk start")
s=5
case 1008
=#pt("Mähwerk gestartet")
s=5
case 1012
=#pt("Signal starte Mähwerk")
s=5
case 1014
=#pt("Laden")
s=1
case 1016
=#pt("in LS wartend")
s=2
case 1024
=#pt("aus LS einfahren")
s=4
case 1036
=#pt("Viereckmodus")
s=5
case 1038
=#pt("Festgefahren")
case 1040
=#pt("Kollision")
s=4
case 1042
=#pt("Suchen")
s=4
case 1044
=#pt("Stop")
case 1048
=#pt("Andocken")
s=2
case 1050
=#pt("aus LS ausfahren")
s=4
case 1052
=#pt("Fehler")
case 1056
=#pt("Wartet Man./Home")
s=2
case 1058
=#pt("Begrenzung folg.")
s=4
case 1060
=#pt("N-Signal gefunden")
s=4
case 1062
=#pt("Festgefahren")
case 1064
=#pt("Suchen")
s=4
case 1066
=#pt("Fernverfolgungsproblem")
s=3
case 1070
=#pt("Suchschleife folgen")
s=4
case 1072
=#pt("Schleife folgen")
s=4
ends
;reduce traffic if mower is not in action
if s<4
{
tper=30
} else {
tper=10
}

#pt(tt)
print Status: %tt% %0tper%

#sd(ss)
;sends data to robo
=>SerialSend5 %ss%

>J
;add data to MQTT sensor publish
,"status":%0st%,"sstate":%0s%,"mow time":%0mt%,"time since chg":%0tc%,"batt current":%0ak%,"batt charge time":%0ct%,"batt charged":%0cb%,"batt temp":%0bt%,"batt used":%0uc%,"batt voltage":%0bv%,"batt capacity":%0nc%

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/community/thre…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.

Zitat von sunburstc

Allerdings habe ich doch starke Abweichungen beim Verbrauch. Mein via IR Transistor ausgelesener Q3B hat über 24h fast 1kW mehr Verbrauch auf der Uhr als es der SBC hat.

Im Allgemeinen würde ich sagen, dass die Janiza oder auch SDM Geräte genauer auflösen.

Wie sind deine Erfahrungen damit?

Hi Sunburst,

gesundes Neues

Finale Aussage zu den Thema (s.o.): nach knapp 4 Monaten und 1560 kWh sind es immer noch ca. 1,2% Abweichung.

Also ich denke die Dinger liegen im Limit. Viel Erfolge noch!

Ekkehard.

Zitat von Maik_Vulkan

Und noch ein Post:

Hat jemand hier schon einen ORNO OR-WE-516 oder OR-WE-517 im Einsatz und erfolgreich ausgelesen? Die gbits für rund 60€ bei amazon und ich habe mir gerade einen bestellt. Die Zähler können per Modbus via klemmen oder IR-LED ausgelesen werden. <-- ist das hier eigentlich unerlaubte Werbung? Ich habe jedenfalls keine Beziehung zu denen und war nur auf der Suche nach günstigen Stromzählern, die man gut auslesen kann. Wenn ich hier etwas falsch mache, bitte ich um Entschuldigung.

Schau mal hier, die Zähler bekommst Du günstiger und massenweise beim eBay (wenn Du noch welche brauchst), frag einfach bei dem Verkäufer dort nach. Musst Du nur noch nachbauen. Um Deinen was zu entlocken brauchst Du sicher ein paar Tools. Steht auch was dazu drin. MODBUS ist ja ideal für Dich, wenn Du mehrere Zähler brauchst! Viel Erfolg!

Ekkehard.

Zitat von sunburstc

....

Allerdings habe ich doch starke Abweichungen beim Verbrauch. Mein via IR Transistor ausgelesener Q3B hat über 24h fast 1kW mehr Verbrauch auf der Uhr als es der SBC hat.

Im Allgemeinen würde ich sagen, dass die Janiza oder auch SDM Geräte genauer auflösen.

Wie sind deine Erfahrungen damit?

Hi Sunburstc,

Kann nun was zu den Abweichungen sagen: in beiden Fällen liegt die bei etwas über 1%, in beiden Fällen zählen die Ferrariszähler des Versorgers etwas mehr. Die SAIA's sind mit Genauigkeitsklasse B oder 1 (je nach Norm) angegeben, nach dem was ich so gefunden habe sind das +/-1%. Die Ferraris sind Klasse 2, habe auf die Schnelle keine Infos gefunden was das bedeutet.

Die Abweichungen scheinen demnach also im Limit zu liegen (über mittlerweile 490 und 270 kWh gemessen).

Und mal ganz allgemein (z.B. mafrei Ihr könnt Euch die originalen Quellen vom Tasmota runterladen, ist im Moment 8.1. Der SML Treiber ist da drin. Ihr müsst natürlich die userconfig anpassen.

Das Git von GEMU ist eine Entwicklerversion, für den Einsteiger vielleicht etwas schwieriger zu handhaben. Der Treiber scheint ja mittlerweile fix zu sein.

sunburstc

Mit dem Zähler habe ich noch keine Langzeiterfahrungen. Ich werde das jetzt beobachten, der Erste ist jetzt in der Verteilung eingebaut. Habe ja den Zähler vom Versorger zum Vergleich.

Ich hatte vorher einen mit S0 drin, das war mir zu viel Gefrickel. Hatte den am einem Sonoff 4CH, der hat sich nur verzählt. War direkt S0, also ohne LED usw.. Würde ich künftig immer vermeiden wenns geht.

Ich wollte den Zähler auch schon für defekt erklären, hab dann einen zweiten bekommen mit dem gleichen frustrierenden Ergebnis. Der Knackpunkt war das 8E1. Deswegen habe ich auch den Abschnitt mit dem Stick drin, das hat mir dann letztendlich echt geholfen. Wenn man es mal verstanden hat ist es eigentlich doch gar nicht so schwer..

Es ist letztendlich wie immer: Step by Step, kleine Schritte machen...

Wie auch immer: den Zweiten muss ich heute noch in meiner WP unterbringen und die 8V vom Klingeltrafo zu 3,3V machen. Dann habe ich zwei Vergleiche. Ich lass dann was von mir hören..

Hallo an alle,

nachdem ich nun eine Weile hier mitgelesen habe, habe ich mich an die Einbindung zweier MODBUS-Zähler gewagt.

Das Studium dieses Blogs ist mittlerweile zu einer Herausforderung geworden, es werden hier die verschiedensten Zählertypen diskutiert und der Treiber entwickelt sich auch immer noch stürmisch weiter. So hat es bei mir eine Weile gedauert erfolgreich zu sein. Falls also jemand das Gleiche mal vorhat, hier ein paar Anregungen/ Hilfestellungen, speziell auf MODBUS bezogen. MODBUS, in diesem Falle als RTU unidirektional (also einfache Zweidrahtleitung) ist übrigens ein verbreiteter Standart für die Gerätekommunikation in der Steuer- und Regelungstechnik. Mit dem SML-Treiber bekommt TASMOTA einen einfachen Zugang dazu.

Alle Links auf Produkte verstehen sich sebstverständlich nur als Beispiele, ich bin da nirgends dran beteiligt..

Ich habe zwei Saia PCD ALE3D5F D10C3A07 Zähler, davon gibt es übrigens derzeit eine Menge bei eBay. Aufpassen, die haben verschiedenen Busse, MBus ist übrigens nicht gleich MODBUS. Die beiden kommen bei mir hinter die beiden Zähler vom Versorger, die Preise machen es möglich. In meinem Falle sind es keine Zweirichtungszähler.

Um von der Seriellen auf den MODBUS des Zählers zu kommen braucht man einen RS232<>RS485 Wandler. Auch hier aufpassen: ein reiner TTL-Wandler wie dieser hier funktioniert erstmal nicht in beide Richtungen. Dazu kam bei mir ein ESP01 als kleinster Vertreter der ESP828x Gattung. Für zwei Zähler, mit allen Spannungen, Strömen usw. reicht der Scriptspeicher nicht aus. Mit einem Zähler klappt es gerade so, beschränkt man sich auf wenige Messwerte (kWh, Leistung) geht es auch mit zweien. So braucht man in diesem Falle also noch einen I2C EEPROM. Neben Tx und Rx benötigt man so noch zwei freie GPIO's und das bekommt man am ESP01 geboten.

Mit dem gegebenen Script bleiben dann noch ca. 1330 Zeichen frei, genug für noch ein paar Berechnungen.

Der RS232<>485 Wandler kommt bei mir an den Hardware TX/RX des ESP01, hierbei die Leitungen nicht kreuzen (jedenfalls für diesen Adapter). Tx an Tx und Rx an Rx. Das wird nicht im Gerätekonfigmenue eingetragen! Den I2C-Speicher habe ich mit je einem 3,3k Pull Up an GPIO0 (SCL) und GPIO2 (SDA) angeschlossen, dieser wird eingetragen (siehe Bild unten). Beide GPIO's müssen beim Start auf High liegen, auch deswegen die Pull Up's. Klappt vorzüglich, der ESP bootet anstandslos.

Das Ganze ist auf einer Uni-Platine verlötet und auf einen (SONOFF)-Hutschienenadapter montiert. Siehe Bild unten. Ein Elko in der Nähe des ESP01 sorgt für stabile Spannungsverhältnisse.

Die Saia-Zähler haben die MODBUS-Anschlüsse D und /D, der D ist dem B- und der /D dem A+ gleichzusetzen. Nicht vergessen: ein Modbus muss an den Enden mit jeweils 120Ohm abgeschlossen werden (siehe im Bild die Widerstände an den Zählern). Zum MODBUS wird man hier fündig.

Für die Inbetriebnahme und Fehlersuche kann man übrigens gut den RS232 Wandler (siehe oben) zusammen mit dem USB-Programmieradapter verwenden, um mittels eines Terminalprogrammes (was HEX darstellen kann, wie z.B. CoolTerm auf dem Mac) sehr schön zu sehen, was passiert. Es gibt natürlich auch gleich fertige Adapter (hier auf Basis C340), die letztendlich nix anderes sind.

Man kann auch mit QModMaster (das ist nun leider mal für Windows ) per Auswahl Register beschreiben und lesen. Das war für mich alles ganz hilfreich um herauszufinden das die Saia's 8E1 als serielles Hardwareprotokoll nutzen.

Man braucht das hier also nur, wenn man in TASMOTA nach Eingabe von sensor53 d1 nichts zu sehen bekommt.

TASMOTA muss für diesen Einsatzfall bekannterweise selbst kompiliert werden. Dazu sind einige Compilerschalter zwingend notwendig. Wie das alles grundsätzlich geht findet man wirklich oft genug hier in den Foren beschrieben. Die folgenden, notwendigen Schalter packt man am besten in die user_config_override:

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

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

#define USE_SCRIPT_WEB_DISPLAY

#define USE_24C256 //EEPROM zur Scriptspeichererweiterung, kann übrigens auch ohne drin bleiben

#ifndef USE_SML_M

#define USE_SML_M

#endif

#define SML_MAX_VARS 50

#define METER_DEF_SIZE 3000

Die beiden letzten Parameter sind brandneu, von heute, und werden erst benötigt, wenn es zwei Zähler mit der Folge dieser Anzahl an Decoderzeilen (38) werden. SML_MAX_VARS hieß früher MAX_VARS (nicht zu verwechseln mit MAXVARS aus dem Script selbst). METER_DEF_SIZE (Standart = 2000) ist nun auch über die user_config_override erreichbar, ab ca. 27 Decodern erhöht man das. Sollten diese Parameter zu klein sein, merkt man dass daran, das auf dem WEB-Interface OBIS angezeigt wird, der Trigger >M im Scripter also nicht startet

Bei mir laufen die Zähler auf den MODBUS-Adressen 01 und 03 (wie gleich im Script zu sehen sein wird). Man muss beachten, das der ganze Modbus aus Sicht TASMOTA's als ein Zähler gilt, die beiden Saia's werden über ihre MODBUS-Geräteadressen unterschieden. Also >M 1.

Was mich auch noch Zeit gekostet hat: Bei der Definition des MODBUS-Zählers selbst ist "m" und "M" ein Klein was Anderes: 8N1 oder 8E1 als serielles Hardwareprotokoll. Steht nun auch in der Doku.

Für das Script habe ich auf die Vorarbeit von sunburst hier aus dem Blog zurückgegriffen, bei dem ich mich herzlich bedanke.

Und auch an dieser Stelle nochmal Danke an den Theo Arends, der dieses herrliche Tasmota erfunden hat und an GEMU, der mit seinem Script und nun mit diesem SML-Treiber (und noch anderen Dingen) ganz tolle Erweiterungen geschaffen hat und diese in bemerkenswerter Geschwindigkeit weiterentwickelt. Ich kann Script wirklich nur jedem ans Herz legen.

So nun das Script (es sind übrigens nicht alle möglichen Werte des Zählers enthalten):

>D

>B

=>sensor53 r

>M 1

+1,3,M,1,9600,Meter,1,1,01030023,01030028,0103002d,01030025,0103002a,0103002f,01030032,01030027,0103002c,01030031,0103001B,0103001d,03030023,03030028,0303002d,03030025,0303002a,0303002f,03030032,03030027,0303002c,03030031,0303001B,0303001d

1,=h Domestic Electricity:

1,010304UUuuUUuuxxxx@i10:100,1 Tariff 1 total,kWh,M1_T1_total,2

1,010304UUuuUUuuxxxx@i11:100,1 Tariff 1 partial,kWh,M1_T1_par,2

1,=h Readings:

1,010304UUuuxxxxxxxx@i0:1,1 Voltage L1,V,M1_Voltage_L1,0

1,010304UUuuxxxxxxxx@i1:1,1 Voltage L2,V,M1_Voltage_L2,0

1,010304UUuuxxxxxxxx@i2:1,1 Voltage L3,V,M1_Voltage_L3,0

1,010304xxxxUUuuxxxx@i0:10,1 Current L1,A,M1_Current_L1,2

1,010304xxxxUUuuxxxx@i1:10,1 Current L2,A,M1_Current_L2,2

1,010304xxxxUUuuxxxx@i2:10,1 Current L3,A,M1_Current_L3,2

1,010304UUuuxxxxxxxx@i3:100,1 Active Power L1,kW,M1_PRMS_L1,3

1,010304UUuuxxxxxxxx@i4:100,1 Active Power L2,kW,M1_PRMS_L2,3

1,010304UUuuxxxxxxxx@i5:100,1 Active Power L3,kW,M1_PRMS_L3,3

1,010304UUuuxxxxxxxx@i6:100,1 Active Power total,kW,M1_PRMS_total,3

1,010304xxxxSSssxxxx@i3:100,1 Reactive Power L1,kVAr,M1_QRMS_L1,3

1,010304xxxxSSssxxxx@i4:100,1 Reactive Power L2,kVAr,M1_QRMS_L2,3

1,010304xxxxSSssxxxx@i5:100,1 Reactive Power L3,kVAr,M1_QRMS_L3,3

1,010304xxxxSSssxxxx@i6:100,1 Reactive Power total,kVAr,M1_QRMS_total,3

1,010304UUuuxxxxxxxx@i7:100,1 CosPhi L1,,M1_CosPhi_L1,2

1,010304UUuuxxxxxxxx@i8:100,1 CosPhi L2,,M1_CosPhi_L2,2

1,010304UUuuxxxxxxxx@i9:100,1 CosPhi L3,,M1_CosPhi_L3,2

1,=h________________________________________________

; meter 2 +12 offset

1,=h Heat Pump

1,030304UUuuUUuuxxxx@i22:100,2 Tariff 1 total,kWh,M2_T1_total,2

1,030304UUuuUUuuxxxx@i23:100,2 Tariff 1 partial,kWh,M2_T1_par,2

1,=h Readings:

1,030304UUuuxxxxxxxx@i12:1,2 Voltage L1,V,M2_Voltage_L1,0

1,030304UUuuxxxxxxxx@i13:1,2 Voltage L2,V,M2_Voltage_L2,0

1,030304UUuuxxxxxxxx@i14:1,2 Voltage L3,V,M2_Voltage_L3,0

1,030304xxxxUUuuxxxx@i12:10,2 Current L1,A,M2_Current_L1,2

1,030304xxxxUUuuxxxx@i13:10,2 Current L2,A,M2_Current_L2,2

1,030304xxxxUUuuxxxx@i14:10,2 Current L3,A,M2_Current_L3,2

1,030304UUuuxxxxxxxx@i15:100,2 Active Power L1,kW,M2_PRMS_L1,3

1,030304UUuuxxxxxxxx@i16:100,2 Active Power L2,kW,M2_PRMS_L2,3

1,030304UUuuxxxxxxxx@i17:100,2 Active Power L3,kW,M2_PRMS_L3,3

1,030304UUuuxxxxxxxx@i18:100,2 Active Power total,kW,M2_PRMS_total,3

1,030304xxxxSSssxxxx@i15:100,2 Reactive Power L1,kVAr,M2_QRMS_L1,3

1,030304xxxxSSssxxxx@i16:100,2 Reactive Power L2,kVAr,M2_QRMS_L2,3

1,030304xxxxSSssxxxx@i16:100,2 Reactive Power L3,kVAr,M2_QRMS_L3,3

1,030304xxxxSSssxxxx@i18:100,2 Reactive Power total,kVAr,M2_QRMS_total,3

1,030304UUuuxxxxxxxx@i19:100,2 CosPhi L1,,M2_CosPhi_L1,2

1,030304UUuuxxxxxxxx@i20:100,2 CosPhi L2,,M2_CosPhi_L2,2

1,030304UUuuxxxxxxxx@i21:100,2 CosPhi L3,,M2_CosPhi_L3,2

#

Was dabei rauskommt sieht man im angehängten Bild.

Hoffe es hilft dem Einen oder Anderen.

Viele Grüße

Ekkehard.

Was hast Du da eigentlich für einen Solarspeicher?

Die Sensoren bekommen den Index vom Tasmota verabreicht. Das sieht dann als JSON Payload so aus:

{"Time":"2019-08-22T12:53:02","DS18B20_1":{"Id":"01131BB08E7C","Temperature":26.5},"DS18B20_2":{"Id":"0114542738AA","Temperature":23.7},"DS18B20_3":{"Id":"01145430AEAA","Temperature":24.0},"TempUnit":"C"}

Der Index ist die _1 _2.. hinter dem Sensor.

Du kannst die Zuordnung nicht ändern, die ergibt sich vermute mal aus der Reihenfolge der Seriennummern. Ändert sich also erst wenn Du einen Sensor tauschen musst. In Domoticz musst Du dann den Payload "auseinandernehmen", das ist da sicher schon drin.

Denk an die setoption64 1., sonst klappt das nicht mit dem Index.

Wenn Du den Mosquitto laufen hast solltest Du das in Deiner Clientapp unter tele/SENSOR eigentlich schon sehen.

Zu Domoticz kann ich nicht viel sagen. Es hat aber ein MQTT Interface (https://www.domoticz.com/wiki/MQTT). Damit dürfte das kein Problem sein und wird bei FHEM und NodeRed genau so gemacht. Einen Broker installieren (Mosquitto auf einen Raspi?), den Sonoff an den Broker anmelden (im Menü MQTT), das war es schon auf der Sonoff Seite, er published seine Werte ganz von selbst. Die Relais kannst Du auch schalten.

Wichtig ist setoption64 auf 1 zu setzen, dann werden die - beim Index gegen _ getauscht. Das - wird als Minus interpretiert und klappt nicht.

Bei mir laufen 3 Sensoren stabil, 8 sind möglich. Du musst halt nur sehen welcher welchen Index bekommt, das kann man nicht beeinflussen.