It looks like this:
.
Time, tensions
.
Time, tensions
Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam
michal.zd wrote:.5. In domoticz you need to add something, here hints @Daro1003
.
michal.zd wrote:.Aa, so domoticz has some of its default sensors. Isn't there voltage and current together?
michal.zd wrote:.And does it make any difference? If you set temp and humidity it will receive data?
michal.zd wrote:What's on that list in the picture?
.
.
.
Daro1003 wrote:.From this list you can see that temperature and humidity can be had in one block and something else and that's it in total.
Daro1003 wrote:.Then it will be ok.
#domoticz
domoticz_topic domoticz/in
domoticz_inverter_state 1020
domoticz_pvpower_idx 1026
domoticz_gridpower_idx 1027
domoticz_consumption_idx 1028
# informacja o napieciach i pradach stringów PV
domoticz_pv1_voltage_idx 1030
domoticz_pv1_current_idx 1031
domoticz_pv2_voltage_idx 1032
domoticz_pv2_current_idx 1033
TL;DR: On a Raspberry Pi 1B+, pvInverterBroker reads Sofar KTL/HYD data through the LSW-3 logger and publishes MQTT; “All clear,” after testing showed PZEM and inverter data differed by only 1–2%. This FAQ helps Sofar users decode 65535-style values, verify power registers, and connect data to Node-RED or Domoticz. [#21420031]
Why it matters: Correctly interpreting Sofar Modbus power registers decides whether your automations react to real PV, grid, battery, and house-consumption data or to misleading raw values.
| Option | Data path | Best use | Key limitation |
|---|---|---|---|
| Node-RED + MQTT | Inverter → pvInverterBroker → mosquitto → Node-RED | Flexible parsing and automation | Easy to misconfigure topic, flow, or Deploy |
| Direct Domoticz MQTT | Inverter → pvInverterBroker → Domoticz | Fewer steps, faster setup | Requires correct IDX mapping |
| Raw SolarMan graphs | Inverter cloud view | Quick visual check | Data is approximated every few minutes |
Key insight: On Sofar HYD models,
ActivePower_Output_Totalis not simply total three-phase house load. In the tested hybrid case, it behaved like total AC output related to PV and battery flow, while separate grid and consumption values were needed for a complete HEMS/MEMS picture. [#21409368]
/etc/ime. 2. Enter the LSW-3 WiFi logger IP, serial data, and MQTT topic settings. 3. Run ./inverterbroker -d for testing, or later as a service on Raspberry Pi OS, which was noted as Debian-based. The broker was built for Linux and was already proven on OpenWrt, Debian, and Raspberry Pi. [#21453569]65535 meant -1 decaWatt, 65532 meant -4 decaWatts, and 65531 meant -5 decaWatts. In watts, that is -10 W, -40 W, and -50 W. The thread explicitly corrected the unit: the raw power field was in decaWatts, not watts. At night, these negative values indicated power flowing the opposite way, such as battery charging or grid draw. [#21409342]ActivePower_Output_Total is a Sofar Modbus power register, but it does not mean the same thing on all models. "ActivePower_Output_Total" is a Modbus power register that reports inverter-side active power, with model-specific sign behavior and interpretation. In the thread, the HYD documentation described it as int_16 with “Charge is positive, Discharge is negative,” valid for HYD models. For online KTL inverters, the same register was described as unsigned, which matched the author’s on-grid 15KTL-X G3 behavior. [#21408458]ActivePower_Output_Total could show signed values linked to battery behavior. Later checks showed the sum of phase U×I aligned with total consumption or other screen values, not always with ActivePower_Output_Total. That mismatch was the clue that hybrid models expose PV, battery, grid, and load through separate meanings. [#21409373]activePower_PCC_Total as “positive to fed into the grid, negative to draw from the grid.” That differs from PV production power and also from candidate load registers such as ActivePower_Load_Total and ActivePower_Load_Sys. [#21409803]Grid was negative when the system drew from the grid, and Power became negative when raw 16-bit values were converted correctly. One worked example linked 65531 to -40 W on the inverter display as “Total AC Output Power：-40.00W.” The author concluded that a negative value could mean the battery was charging while energy came from the grid. [#21409342]mqtt in node for the broker topic, connect it to debug, and deploy the flow. 1. In Node-RED, add mqtt in and point it to your mosquitto server. 2. Subscribe to the ready-made JSON topic, which the thread described as most convenient for Node-RED. 3. Link a debug node to inspect the incoming msg object in the sidebar. The thread specifically recommended the ime/inverter/json topic for this. [#21420031]mosquitto_sub showed voltage data, but Node-RED received nothing because the topic string contained an extra space before /state and /json, and the flow had not been deployed. The author also reminded the user to restart the broker after editing the config. This was a pure configuration fault, not an inverter fault. [#21420505]ActivePower_Output_Total alone was insufficient. The author wanted at least PV power, grid power, and consumption power to make the logic meaningful, especially on a hybrid system. [#21409368]./inverterbroker -d for testing, then switch to service mode later. The forum described this as “actually now a few steps,” with data appearing directly in Domoticz after setup. [#21453527]voltage;current message, then changed it after testing. The final layout required four separate IDX entries: domoticz_pv1_voltage_idx, domoticz_pv1_current_idx, domoticz_pv2_voltage_idx, and domoticz_pv2_current_idx. IDX values are assigned automatically by Domoticz when each virtual sensor is created. [#21483283]