@bolliy, hallo. Ich bin wieder einen Schritt weiter - meine beiden kaskadierten WR sind im Netz. Und schon kommt der nächste Punkt: ich muss mit dem iOBRoker dann wohl beide WR abfragen, also eine weitere Instanz des sun2000 Adapters öffnen, um die Daten des 2. WR abholen zu können ->> richtig?

Letztlich würde ich gern die zur Zeit erzeugte Gesamtleistung zum Proxy geben, denn ich spiegle mit dem im Adapter eingebauten PROXY die Daten zu meinem SMARTFOX Engergie-Manager. Dort sehe ich momentan nur die vom ersten WR erzeuge Leistung.

In der FusionSolar APP sehe ich die Gesamtleistung. Stellt sich die Frage, ob das HUAWEI Rechenzentrum mir das Gesamtergebnis durch addition erzeugt, oder ob es ein MODBUS Register im Master WR gibt, dass das Additionsergebnis kennt (werde ich heute Abend mal lesen).

Frage zum Proxy: kann der Nur die vom Adapter via MODBUS eingesammelten Daten spiegeln? Oder kann ich ggf. die Addition der Leistungen der WR per Skript vornehmen und dann dem Proxy zum manual zum senden ermuntern?

@negalein , hier mal was aktuelles in der Hoffnung, dass es auch seinen Weg in die Liste findet.VIS.pdf

@bahnuhr said in Huawei Sun2000 & ioBroker via JS script funktioniert:

@leonundjulie

Der Link

klappt nicht.

Auf ein Neues: V3_was_muss_raus.txt

@bolliy dann bin ich hier ja richtig und werde in Kürze mittesten

@skb Danke für Deine Mühe. Dank Deiner Erklärungen denke ich, dass ich es auch verstanden habe.

Das Ergbenis: es läuft (Dein Update auf 6.2 von heute Morgen ist natürlich schon drin ) nachdem ich zwei Schreibfehler korrigiert hatte.

Die finale Version:

{
    "default": {
        "value": "val => { const percentInWatt=Number(3000*{modbus.0.holdingRegisters.41046_Aout_Output_%})/100; const WB_in_Watt=Number({modbus.0.holdingRegisters.41605_car_charge_1_power}); const verbrauch = val - percentInWatt - WB_in_Watt; return verbrauch>1000 ? (verbrauch/1000).toFixed(2) : verbrauch }",
        "unit": "val => { const percentInWatt=Number(3000*{modbus.0.holdingRegisters.41046_Aout_Output_%})/100; const WB_in_Watt=Number({modbus.0.holdingRegisters.41605_car_charge_1_power}); const verbrauch =  val - percentInWatt - WB_in_Watt; return verbrauch>1000 ? 'kW' : 'W' ; }"
    }
}

Und dann sieht es so aus (habe den Heizstab im Boiler auf 20% = 600 W eingestellt) - zufällig kommen auch ein paar Watt von den PV-Feldern, so dass viel Bewegung auf dem Screen ist :
.

Jetzt muss ich alles noch optisch tunen, aber letztendlich sehe ich jetzt 587 W Hausverbrauch. Die Wallbox kann ich in diesem Moment nicht testen weil das eAuto gerade X-MAS Shopping macht

Soweit ist alles top, Danke!

@bolliy Danke, wieder ein Schritt weiter. Ich sehe es dann mal so, dass die Anzeigen meines SMARTFOX - nachdem ich den PROXY aktiviert hatte - noch aus "dem Speicher" kamen .(SMARTFOX ist hier und da ma träge). Folglich hat er anschließend nichts mehr angezeigt, weil dann als IP 000.000.000.000 gewählt habe.

Auf Grund Deine Hilfe habe ich im SMARTFOX die IP auf die IP meines iOBrokers umgestellt. Interessant ist, das man den Port nicht einstellen kann. However, es funktioniert

Das wars dann hoffentlich fürs erste. Danke für die Unterstützung!

@bolliy Hallo Stephan.

Ich habe den SMARTFOX Service angeschrieben und musste letztlich feststellen, dass der Fehler zwischen meinen Ohren lag.

In der Anleitung https://smartfox.de/wp-content/uploads/2022/11/DE_Huawei-WR-auslesen_TCP_01.2023.pdf sind mehrere Szenario aufgezeigt und einen wichtigen Hinweis habe ich übersehen.

Hier die Bilder von den Einstellungen und dann läuft es:

DANKE für die Unterstützung - damit wäre die Version 16 aus meiner Sicht iO.

@bolliy said in Test Adapter sun2000 v0.1.x - Huawei Wechselrichter:

@leonundjulie unter modbus-proxy ist der Haken bei "erweiterte Protokollierung" gesetzt. Er gibt eine Statistik über die Anfragen als json im Log über den modbus- proxy wieder.
LG Stephan

Danke Stephan, jetzt ist wieder Ruhe im Karton.

@homoran

esphome:
  name: weather
  friendly_name: Weather

esp8266:
  board: nodemcuv2

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "V8pXnULJ5OswQhdoEOT+by4DqN/1aoc5bwtUOOIVjv4="

ota:
  - platform: esphome
    password: "413a8bdefb6108e1f06649a7ad415c13"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Weather Fallback Hotspot"
    password: "zo88Vm8sO4Rv"

captive_portal:

web_server:

uart:
  rx_pin: GPIO3
  tx_pin: GPIO1
  baud_rate: 4800
  parity: NONE
  stop_bits: 1
  data_bits: 8

modbus:
  id: modbus1

modbus_controller:
- id: wind_speed_meter
  address: 0x01
  modbus_id: modbus1
  setup_priority: -10
  command_throttle: 200ms
  update_interval: 30s #or whatever you need

- id: wind_direction_meter
  address: 0x02
  modbus_id: modbus1
  setup_priority: -10
  command_throttle: 200ms
  update_interval: 30s #or whatever you need

sensor:
- platform: modbus_controller
  modbus_controller_id: wind_speed_meter
  name: "Wind Speed"
  device_class: wind_speed
  id: wind_speed
  register_type: read
  address: 0x0000
  unit_of_measurement: "m/s"
  value_type: U_WORD
  accuracy_decimals: 1
  filters:
    - multiply: 0.1
    - max:
        window_size: 5
        send_every: 5
    - exponential_moving_average:
        alpha: 0.1
        send_every: 12

- platform: modbus_controller
  modbus_controller_id: wind_direction_meter
  name: "Wind direction gear"
  internal: true
  register_type: read
  address: 0x0000
  value_type: U_WORD
  accuracy_decimals: 0
  on_value:
      - lambda: |-
          switch (int(x)) {
            case 0:
              id(wind_direction_cardinal).publish_state("N");  //North
              break;
            case 1:
              id(wind_direction_cardinal).publish_state("NE"); //North-East
              break;
            case 2:
              id(wind_direction_cardinal).publish_state("E");  //East
              break;
            case 3:
              id(wind_direction_cardinal).publish_state("SE"); //South-East
              break;
            case 4:
              id(wind_direction_cardinal).publish_state("S");  //South
              break;
            case 5:
              id(wind_direction_cardinal).publish_state("SW"); //South-West
              break;
            case 6:
              id(wind_direction_cardinal).publish_state("W");  //West
              break;
            case 7:
              id(wind_direction_cardinal).publish_state("NW"); //North-West
              break;
            default:
              id(wind_direction_cardinal).publish_state("");   //invalid
          }

- platform: modbus_controller
  modbus_controller_id: wind_direction_meter
  name: "Wind direction degree"
  icon: mdi:compass-rose
  register_type: read
  address: 0x0001
  value_type: U_WORD
  accuracy_decimals: 0
  state_class: measurement
  unit_of_measurement: "°"

text_sensor:
  - platform: template
    name: "Wind direction cardinal"
    id: wind_direction_cardinal
    icon: mdi:compass-rose

@wolfgangfb Copy der YAML:

esphome:

name: weather

friendly_name: Weather

esp8266:

board: nodemcuv2

# Enable logging

logger:

# Enable Home Assistant API

api:

encryption:

key: "V8pXnULJ5OswQhdoEOT+by4DqN/1aoc5bwtUOOIVjv4="

ota:

• platform: esphome

password: "413a8bdefb6108e1f06649a7ad415c13"

wifi:

ssid: !secret wifi_ssid

password: !secret wifi_password

# Enable fallback hotspot (captive portal) in case wifi connection fails

ap:

ssid: "Weather Fallback Hotspot"

password: "zo88Vm8sO4Rv"

captive_portal:

web_server:

uart:

rx_pin: GPIO03

tx_pin: GPIO01

baud_rate: 4800

parity: NONE

stop_bits: 1

modbus:

id: modbus1

modbus_controller:

- id: wind_speed_meter

address: 0x1

modbus_id: modbus1

setup_priority: -10

command_throttle: 200ms

update_interval: 30s #or whatever you need

- id: wind_direction_meter

address: 0x2

modbus_id: modbus1

setup_priority: -10

command_throttle: 200ms

update_interval: 30s #or whatever you need

sensor:

- platform: modbus_controller

modbus_controller_id: wind_speed_meter

name: "Wind Speed"

device_class: wind_speed

id: wind_speed

register_type: holding

address: 0x0000

unit_of_measurement: "m/s"

value_type: U_WORD

accuracy_decimals: 1

filters:

- multiply: 0.1

- max:

window_size: 5

send_every: 5

- exponential_moving_average:

alpha: 0.1

send_every: 12

- platform: modbus_controller

modbus_controller_id: wind_direction_meter

name: "Wind direction gear"

internal: true

register_type: holding

address: 0x0000

value_type: U_WORD

accuracy_decimals: 0

on_value:

  - lambda: |-

      switch (int(x)) {

        case 0:

          id(wind_direction_cardinal).publish_state("N");  //North

          break;

        case 1:

          id(wind_direction_cardinal).publish_state("NE"); //North-East

          break;

        case 2:

          id(wind_direction_cardinal).publish_state("E");  //East

          break;

        case 3:

          id(wind_direction_cardinal).publish_state("SE"); //South-East

          break;

        case 4:

          id(wind_direction_cardinal).publish_state("S");  //South

          break;

        case 5:

          id(wind_direction_cardinal).publish_state("SW"); //South-West

          break;

        case 6:

          id(wind_direction_cardinal).publish_state("W");  //West

          break;

        case 7:

          id(wind_direction_cardinal).publish_state("NW"); //North-West

          break;

        default:

          id(wind_direction_cardinal).publish_state("");   //invalid

      }

- platform: modbus_controller

modbus_controller_id: wind_direction_meter

name: "Wind direction degree"

icon: mdi:compass-rose

register_type: read

address: 0x0001

value_type: U_WORD

accuracy_decimals: 0

state_class: measurement

unit_of_measurement: "°"

text_sensor:

• platform: template

name: "Wind direction cardinal"

id: wind_direction_cardinal

icon: mdi:compass-rose

Diesmal geht es um die Idee mit entsprechenden Sensoren alle möglichen Wetterdaten einzusammeln - unter anderem Windrichtung und Windgeschwindigkeiten.

Ich nutze einen PI 4 auf dem ich iOBroker nutze mit diversen Adaptern und möchte in meinem Szenario Wind Speed & direction via ESPHome und Modus abgreifen.

Eckdaten zu den Sensoren:

• Wind speed transmitter (485type) SN-3000-FSJT-N01 https://robu.in/wp-content/uploads/2024/10/12-R183268-SN-3000-FSJT-N01-485-type.pdf

• list itemWind Direction Transmitter (485type) SN-3000-FXJT-N01 https://robu.in/wp-content/uploads/2024/11/1-R183257-SN-3000-FXJT-N01.pdf

Das folgende Bild ist nur zur Info:

Also habe ich den ESPHome Adapter in iOBroker integriert, mir eine nodemmcu v3 gekauft, die Windsensoren und mein erstes YAML aufgesetzt. Es wird alles ohne Fehler kompiliert und der ESPHome arbeitet grundsätzlich. Da ich aber keine Kommunikation mit meinen Wind-Devices hinbekomme bin ich jetzt auf der Fehlersuche.

Das log des ESPHome zeigt folgendes und da irritieren mich die Warnungen - muss ich da was machen? Oder kann ich das ignorieren. Letztlich sehe ich an der flackernden LED des TTL-RS485, dass mein YAML arbeitet, etwas an den Konverter gesendet wird

Habe ich ein iOBroker unabhängiges Problem? Also ein Problem meiner ESPHome Umgebung? Im ESPHome-Forum habe ich kaum Feedback erhalten außer “*das Thema sollte auf Grund der Fehlermeldung eher in der iOBroker Welt besprochen werden”*italicised text

Hat jemand eine Idee?

@skb DANKE FÜR DEINE GEDULD!

Ob 1-phasig oder 3phasig geladen wird, hängt halt vom Überschuss ab. Das regelt eine Energie-Management System und diesen Status greife ich ab. Der Toggelt bei wolkigem Wetter schon mal hin und her - und ich möchte halt sehen, was gerade Sache ist. Daher habe ich den Trigger darauf gelegt. Ändert sich der Wert, ändert sich die Anzeige. Das isoliert eingestellt funktioniert genauso gut wie das Steuern der Anzeige des Autos - hier ist die Veränderung aber die Wallbox. Ich werde mich noch ein wenig mit dem DISPLAY Command auseinandersetzen bzw. Damit, dass ich meinen Value Wert weder auf „1 phasig“, noch auf „3 phasig“ haben möchte, sondern auf „“, wenn die Wallbox mir einen Staus <4 liefert. Sinngemäß:

{
        “0“ : {
                "value": "1 phasig"
               },
        “1“ : {
                "value": "3 phasig"
               },
        “{kecontact.0.plug} < 4“  : {
                "value": ""
               }
}

@skb was für eine schwere Geburt. Ich habe den Datenpunkt gewechselt (0=1 phasig und 1=3phasig).

Und danach habe ich die Überschreibung angepasst:

{
    "0": {
        "value": "1 phasig"
    },
    "1": {
        "value": "3 phasig"
    },
    "display": "() => {kecontact.0.plug} > 3 ? 'inline-block' : 'none'"
}

Frage: ist die Befehlsfolge prinzipiell richtig? Ich weise der Variablen value einen Wert „“1 phasig“ respektive „3 phasig“ zu wenn der Datenpunkt sich ändert. Und in Abhängigkeit des „externen Datenpunktes“ soll entschieden werden, ob die Variable Value überhaupt zur Anzeige gebracht werden. Ich habe sehr viel bzgl DISPLAY gegoogelt, verstehe es wahrscheinlich aber noch immer nicht richtig

Wie dem auch sei, das Ergebnis vor dem Ziehen des Steckers der Wallbox: Foto des Autos zu sehen, Schriftzug „1 phasig“ (kein Sonnenschein, also kein Überschuss)

Und das Ergebnis nach dem Ziehen des Steckers der Wallbox: Foto des Autos nicht mehr zu sehen … ging ja auch schon die ganze Zeit, aber mein Schriftzug „1 phasig“ ist immer noch da:

Ich verzweifle . Es können sich halt zwei Variablen ändern, aber ich kann das Objekt, welches den Wert „1 phasig“ oder „3 phasig“ haben kann, nur der einender der anderen Variablen zuordnen. Muss ich meine Idee aufgeben?

@skb verstanden, werde es drehen (wenn ich mir das wie überlegt habe) und auf Sonne und somit Überschuss warten.

Oder es doch anders machen🧐. Denn ich habe verstanden, dass für die Programmierungen im Rahmen einer Überschreibung der Wert des Datenpunktes herangezogen wird (ist doch korrekt, oder?).

Aber wofür ist der Punkt „Datenquelle zur Steuerung“

@skb , ich habe weiter experimentiert und bin noch immer nicht am Ziel, was sicherlich daran liegt, dass sich mir das DISPLAY COMMAND noch nicht komplett erklärt.

Ich habe für das ID3 Bild den Datenpunkt kecontact.0.plug angezogen und es wie folgt gemacht. Das klappt - das Bild ist da wenn das Auto an der Wallbox hängt und ist nicht zu sehen, wenn der ID3 auf Tour ist.

{
    "default": {
        "display": "val => val > 3 ? 'inline-block' : 'none'"
    }
}

Für meinen Schriftzug 1phasig respektive 3 phasig habe ich den passenden Datenpunkt genommen und den Code wie folgt gesetzt. Zwar wechselt der Schriftzug auf 1-phasig und umgekehrt (je nach Menge des Überschusses. Funktioniert das DISPLAY command an dieser Stelle nicht? In der von mir gewählten Kombi nicht? Oder …?

{
    "0": {
        "fill": "rgb(216,216,216)",
        "value": "1 phasig",
        "display": "() => {kecontact.0.plug} > 3 ? 'inline-block' : 'none'"
    },
    "1": {
        "fill": "rgb(216,216,216)",
        "value": "3 phasig",
        "display": "() => {kecontact.0.plug} > 3 ? 'inline-block' : 'none'"
    }
}

@skb hab es jetzt so gemacht wie Du es vorgeschlagen hast und schon geht es mit meinem Testdatenpunkt. Weil der Datenpunkt meiner Wallbox aber folgende Werte ausgibt

"states": {
  "0": "no cable plugged",
  "1": "cable plugged in charging station, unlocked",
  "3": "cable plugged in charging station and locked",
  "5": "cable plugged in charging station and vehicle, unlocked",
  "7": "cable plugged in charging station and vehicle and locked"
}

habe ich es letztlich so gemacht und mein ID3 Foto kommt jetzt endlich nur noch, wenn der Flitzer angesteckt ist ... egal, ob verriegelt oder nicht.

{
    "default": {
        "display": "val => val > 3 ? 'inline-block' : 'none'"
    }
}

Danke für den Support!!!

Jetzt möchte ich es noch perfekt machen und den Schriftzug "1 phasig respektive 3 phasig ebenfalls ausblenden, wenn der ID3 nicht da ist.

{
    "0": {
        "fill": "rgb(216,216,216)",
        "value": "1 phasig"
    },
    "1": {
        "fill": "rgb(216,216,216)",
        "value": "3 phasig"
    }
}

Ergo müsste ich den folgenden Code ebenfalls in die Abhängigkeit zum DP kecontact.0.plug bringen. Also if kecontact.0.plug > 3, dann 1 phasig oder 3 phasig, ansonsten nichts. Was hältst Du von diesem Ansatz:

{
    "0" and “{kecontact.0.plug} > 3}” : {
        "fill": "rgb(216,216,216)",
        "value": "1 phasig"
    },
    "0" and “{kecontact.0.plug} < 5}” : {
        "fill": "rgb(216,216,216)",
        "value": "1 phasig"
    },
    "1" and “{kecontact.0.plug} > 3}” : {
            "fill": "rgb(216,216,216)",
            "value": "3 phasig"
    },
    "1" and “{kecontact.0.plug} < 5}” : {
        "fill": "rgb(216,216,216)",
        "value": ""
}

@skb letztlich hatte ich zwei Themen:

• darstellen, ob 1-phasig oder 3-phasig geladen wird (der eingebundene Daten Punkt ist =0 oder =1)

• Bildchen des Autos einblenden, wenn es angeschlossen ist (mein Wert respektive der eingebundene Datenpunkt ist dann ungleich 0) …. oder Bildchen des Autos ausblenden, wenn der Datenpunkt=0 ist

Die erste Aufgabe ist gelöst, aber bei der zweiten mit ID3 Bildchen tue ich mich schwer

@skb “… dann mach es doch “ scheint schwieriger als gedacht, zumal diese Sprache fürs ÜBERSCHREIBEN noch sehr fremd ist.

Das Bild meines iD3, im EnergieflussAdapter eingebunden als “ID 256”, bleibt hartnäckig im Bild.

Ich habe bislang folgenden Code versucht (auch mal in der Variation “ID 256” statt “)inline-block”. Den Datenpunkt Plug_Test habe ich natürlich unter Dsatenquelle eingebunden. Wenn ich meinen Datenpunkt zwischen 0 und 1 wechsle, passiert nichts. Daher muss ich nochmals um Hilfe bitten.

{
    "default": {
        "display": "() => {0_userdata.0.Plug_Test} == 0 ? 'inline-block' : 'none'"
    }
}