-
-
Save noone2k/2ddea4c9bf116aaaefb8626b064d9a41 to your computer and use it in GitHub Desktop.
esphome: | |
name: bc2500-ble-idf | |
friendly_name: bc2500-ble-idf | |
esp32: | |
board: az-delivery-devkit-v4 | |
framework: | |
type: esp-idf | |
sdkconfig_options: | |
CONFIG_FREERTOS_UNICORE: y | |
advanced: | |
ignore_efuse_mac_crc: true | |
# Enable logging | |
logger: | |
# level: INFO | |
# level: DEBUG | |
# baud_rate: 0 | |
ota: | |
password: !secret ota_password | |
wifi: | |
ssid: !secret wifi_ssid | |
password: !secret wifi_password | |
reboot_timeout: 0s | |
fast_connect: True | |
# Enable fallback hotspot (captive portal) in case wifi connection fails | |
ap: | |
ssid: "Bc2500-Ble Fallback Hotspot" | |
web_server: | |
port: 80 | |
local: true | |
js_include: "./v2/www.js" | |
js_url: "" | |
version: 2 | |
captive_portal: | |
mqtt: | |
id: mqtt_client | |
broker: !secret mqtt_broker | |
port: !secret mqtt_port | |
discovery: False | |
reboot_timeout: 0s | |
topic_prefix: b2500 | |
log_topic: b2500/debug | |
time: | |
- platform: sntp | |
id: sntp_time | |
on_time: | |
# Every 10 seconds | |
- seconds: /10 | |
then: | |
- script.execute: ble_process | |
- script.wait: ble_process | |
#- script.execute: power_zero | |
#- button.press: query_info3 | |
globals: | |
- id: ble_1_connected | |
type: bool | |
initial_value: '0' | |
- id: ble_1_initialized | |
type: bool | |
initial_value: '0' | |
- id: ble_2_connected | |
type: bool | |
initial_value: '0' | |
- id: ble_2_initialized | |
type: bool | |
initial_value: '0' | |
- id: cmd30_xor_last_1 | |
type: int | |
initial_value: '0' | |
- id: cmd30_xor_last_2 | |
type: int | |
initial_value: '0' | |
- id: internal_console_dbg | |
type: bool | |
initial_value: '0' | |
- id: internal_console_hexdump | |
type: bool | |
initial_value: '1' | |
esp32_ble_tracker: | |
ble_client: | |
- mac_address: !secret hm2500_1_mac | |
id: bc2500_1 | |
on_connect: | |
then: | |
- globals.set: | |
id: ble_1_connected | |
value: '1' | |
- binary_sensor.template.publish: | |
id: bool_ble_ok_1 | |
state: ON | |
- script.execute: | |
id: ble_set_time | |
ble_device_nr: 1 | |
- script.wait: ble_set_time | |
- script.execute: | |
id: ble_set_time | |
ble_device_nr: 1 | |
- script.wait: ble_set_time | |
on_disconnect: | |
then: | |
- binary_sensor.template.publish: | |
id: bool_ble_ok_1 | |
state: OFF | |
- globals.set: | |
id: ble_1_connected | |
value: '0' | |
- globals.set: | |
id: ble_1_initialized | |
value: '0' | |
- mac_address: !secret hm2500_2_mac | |
id: bc2500_2 | |
on_connect: | |
then: | |
- globals.set: | |
id: ble_2_connected | |
value: '1' | |
- binary_sensor.template.publish: | |
id: bool_ble_ok_2 | |
state: ON | |
- script.execute: | |
id: ble_set_time | |
ble_device_nr: 2 | |
- script.wait: ble_set_time | |
- script.execute: | |
id: ble_set_time | |
ble_device_nr: 2 | |
- script.wait: ble_set_time | |
on_disconnect: | |
then: | |
- binary_sensor.template.publish: | |
id: bool_ble_ok_2 | |
state: OFF | |
- globals.set: | |
id: ble_2_connected | |
value: '0' | |
- globals.set: | |
id: ble_2_initialized | |
value: '0' | |
button: | |
- platform: restart | |
id: controller_restart | |
name: "Restart Controller" | |
number: | |
- platform: template | |
name: "D1-52: Entladeschwelle" | |
id: sensor_discharge_treshold_1 | |
state_topic: b2500/1/battery/discharge_treshold | |
command_topic: b2500/1/battery/discharge_treshold/set | |
optimistic: True | |
min_value: 1 | |
max_value: 500 | |
step: 1 | |
restore_value: True | |
on_value: | |
- script.execute: | |
id: ble_set_discharge_treshold | |
ble_device_nr: 1 | |
discharge: !lambda return x; | |
- platform: template | |
name: "D1-53: DOD" | |
state_topic: b2500/1/battery/dod | |
command_topic: b2500/1/battery/dod/set | |
id: sensor_dod_1 | |
optimistic: True | |
min_value: 10 | |
max_value: 100 | |
step: 1 | |
restore_value: True | |
on_value: | |
- script.execute: | |
id: ble_set_dod | |
ble_device_nr: 1 | |
dod: !lambda return x; | |
- platform: template | |
name: "D2-52: Entladeschwelle" | |
id: sensor_discharge_treshold_2 | |
state_topic: b2500/2/battery/discharge_treshold | |
command_topic: b2500/2/battery/discharge_treshold/set | |
optimistic: True | |
min_value: 1 | |
max_value: 500 | |
step: 1 | |
restore_value: True | |
on_value: | |
- script.execute: | |
id: ble_set_discharge_treshold | |
ble_device_nr: 2 | |
discharge: !lambda return x; | |
- platform: template | |
name: "D2-53: DOD" | |
state_topic: b2500/2/battery/dod | |
command_topic: b2500/2/battery/dod/set | |
id: sensor_dod_2 | |
optimistic: True | |
min_value: 10 | |
max_value: 100 | |
step: 1 | |
restore_value: True | |
on_value: | |
- script.execute: | |
id: ble_set_dod | |
ble_device_nr: 2 | |
dod: !lambda return x; | |
### power zero | |
- platform: template | |
name: "MQTT: opendtu set limit" | |
id: mqtt_opendtu_limit | |
internal: False | |
state_topic: !secret mqtt_opendtu_limit_cmd | |
command_topic: !secret mqtt_opendtu_limit_state | |
optimistic: True | |
min_value: 1 | |
max_value: 75 | |
step: 1 | |
restore_value: True | |
- platform: template | |
name: "MQTT: opendtu set limit max" | |
id: mqtt_opendtu_limit_max | |
internal: False | |
optimistic: True | |
min_value: 1 | |
max_value: 75 | |
step: 1 | |
restore_value: True | |
switch: | |
- platform: template | |
id: switch_powerout_1_1 | |
name: "D1-01: Power Out 1" | |
state_topic: b2500/1/power1/enabled | |
command_topic: b2500/1/power1/enabled/set | |
optimistic: True | |
assumed_state: True | |
on_turn_on: | |
then: | |
- switch.turn_on: switch_powerout_1_1 | |
- script.execute: | |
id: ble_powerout | |
ble_device_nr: 1 | |
on_turn_off: | |
then: | |
- switch.turn_off: switch_powerout_1_1 | |
- script.execute: | |
id: ble_powerout | |
ble_device_nr: 1 | |
- platform: template | |
id: switch_powerout_1_2 | |
name: "D1-02: Power Out 2" | |
state_topic: b2500/1/power2/enabled | |
command_topic: b2500/1/power2/enabled/set | |
optimistic: True | |
assumed_state: True | |
on_turn_on: | |
then: | |
- switch.turn_on: switch_powerout_1_2 | |
- script.execute: | |
id: ble_powerout | |
ble_device_nr: 1 | |
on_turn_off: | |
then: | |
- switch.turn_off: switch_powerout_1_2 | |
- script.execute: | |
id: ble_powerout | |
ble_device_nr: 1 | |
- platform: template | |
id: switch_powerout_2_1 | |
name: "D2-01: Power Out 1" | |
state_topic: b2500/2/power1/enabled | |
command_topic: b2500/2/power1/enabled/set | |
optimistic: True | |
assumed_state: True | |
on_turn_on: | |
then: | |
- script.execute: | |
id: ble_powerout | |
ble_device_nr: 2 | |
on_turn_off: | |
then: | |
- script.execute: | |
id: ble_powerout | |
ble_device_nr: 2 | |
- platform: template | |
id: switch_powerout_2_2 | |
name: "D2-02: Power Out 2" | |
state_topic: b2500/2/power2/enabled | |
command_topic: b2500/2/power2/enabled/set | |
optimistic: True | |
assumed_state: True | |
on_turn_on: | |
then: | |
- script.execute: | |
id: ble_powerout | |
ble_device_nr: 2 | |
on_turn_off: | |
then: | |
- script.execute: | |
id: ble_powerout | |
ble_device_nr: 2 | |
- platform: template | |
id: switch_pv2_passthrough_1 | |
name: "D1-03: PV2 Passtrough" | |
state_topic: b2500/1/pv2/passtrough | |
command_topic: b2500/1/pv2/passtrough/set | |
optimistic: True | |
assumed_state: True | |
on_turn_on: | |
then: | |
- script.execute: | |
id: ble_passthrough | |
ble_device_nr: 1 | |
switch_cmd: 0 | |
on_turn_off: | |
then: | |
- script.execute: | |
id: ble_passthrough | |
ble_device_nr: 1 | |
switch_cmd: 1 | |
- platform: template | |
id: switch_pv2_passthrough_2 | |
name: "D2-03: PV2 Passtrough" | |
state_topic: b2500/2/pv2/passtrough | |
command_topic: b2500/2/pv2/passtrough/set | |
optimistic: True | |
assumed_state: True | |
on_turn_on: | |
then: | |
- script.execute: | |
id: ble_passthrough | |
ble_device_nr: 2 | |
switch_cmd: 0 | |
on_turn_off: | |
then: | |
- script.execute: | |
id: ble_passthrough | |
ble_device_nr: 2 | |
switch_cmd: 1 | |
- platform: template | |
id: switch_debug_hexdump | |
name: "INTERNAL:DEBUG HEXDUMP" | |
optimistic: True | |
#assumed_state: True | |
- platform: template | |
id: switch_opendtu_limit | |
name: "MQTT: opendtu - zero power" | |
optimistic: True | |
#assumed_state: True | |
text: | |
- platform: template | |
name: "A1-t01 - Device Type" | |
id: txt_A01_1 | |
state_topic: b2500/1/device/type | |
optimistic: true | |
max_length: 30 | |
mode: text | |
- platform: template | |
name: "A1-t02 - Device ID" | |
state_topic: b2500/1/device/id | |
id: txt_A02_1 | |
optimistic: true | |
max_length: 30 | |
mode: text | |
- platform: template | |
name: "A1-t03 - MAC" | |
id: txt_A03_1 | |
state_topic: b2500/1/device/ble_mac | |
optimistic: true | |
max_length: 30 | |
mode: text | |
- platform: template | |
name: "A1-t04 - SSID" | |
id: txt_A11_1 | |
state_topic: b2500/1/device/wifi_ssid | |
optimistic: true | |
max_length: 30 | |
mode: text | |
- platform: template | |
name: "A2-t01 - Device Type" | |
id: txt_A01_2 | |
state_topic: b2500/2/device/type | |
optimistic: true | |
max_length: 30 | |
mode: text | |
- platform: template | |
name: "A2-t02 - Device ID" | |
id: txt_A02_2 | |
state_topic: b2500/2/device/id | |
optimistic: true | |
max_length: 30 | |
mode: text | |
- platform: template | |
name: "A2-t03 - MAC" | |
id: txt_A03_2 | |
optimistic: true | |
state_topic: b2500/2/device/ble_mac | |
max_length: 30 | |
mode: text | |
- platform: template | |
name: "A2-t04 - SSID" | |
id: txt_A11_2 | |
state_topic: b2500/2/device/wifi_ssid | |
optimistic: true | |
max_length: 30 | |
mode: text | |
- platform: template | |
name: "A1-t56: Szene" | |
id: txt_scene_1 | |
state_topic: b2500/1/device/scene | |
optimistic: true | |
max_length: 32 | |
mode: text | |
- platform: template | |
name: "A1-t57: Region" | |
id: txt_region_1 | |
state_topic: b2500/1/device/region | |
optimistic: true | |
max_length: 8 | |
mode: text | |
- platform: template | |
name: "A2-t56: Szene" | |
id: txt_scene_2 | |
state_topic: b2500/2/device/scene | |
optimistic: true | |
max_length: 32 | |
mode: text | |
- platform: template | |
name: "A2-t57: Region" | |
id: txt_region_2 | |
state_topic: b2500/2/device/region | |
optimistic: true | |
max_length: 8 | |
mode: text | |
binary_sensor: | |
- platform: template | |
name: "D1-i01: PV 1 - Aktiv" | |
id: bool_pv_active_1_1 | |
state_topic: b2500/1/pv1/active | |
- platform: template | |
name: "D1-i11: PV 2 - Aktiv" | |
id: bool_pv_active_1_2 | |
state_topic: b2500/1/pv2/active | |
- platform: template | |
name: "D1-i02: PV 1 - Transparent" | |
id: bool_pv_transparent_1_1 | |
state_topic: b2500/1/pv1/transparent | |
- platform: template | |
name: "D1-i11: PV 2 - Transparent" | |
id: bool_pv_transparent_1_2 | |
state_topic: b2500/1/pv2/transparent | |
- platform: template | |
name: "D1-i54: Wifi Connected (?)" | |
id: bool_wifi_ok_1 | |
state_topic: b2500/1/device/wifi_ok | |
- platform: template | |
name: "D1-i55: MQTT1 Connected" | |
id: bool_mqtt1_ok_1 | |
state_topic: b2500/1/device/mqtt_ok | |
- platform: template | |
name: "D1-i58: BLE Connected" | |
id: bool_ble_ok_1 | |
state_topic: b2500/1/device/ble_ok | |
- platform: template | |
name: "D1-i21: Ausgang 1 - Aktiv" | |
id: bool_power_active_1_1 | |
state_topic: b2500/1/power1/active | |
- platform: template | |
name: "D1-i31: Ausgang 2 - Aktiv" | |
id: bool_power_active_1_2 | |
state_topic: b2500/1/power2/active | |
- platform: template | |
name: "D1-i40: Erweiterung 1 - angeschlossen" | |
id: bool_extern_connected_1_1 | |
state_topic: b2500/1/extern1/connected | |
- platform: template | |
name: "D1-i41: Erweiterung 2 - angeschlossen" | |
id: bool_extern_connected_1_2 | |
state_topic: b2500/1/extern2/connected | |
- platform: template | |
name: "D2-i01: PV 1 - Aktiv" | |
id: bool_pv_active_2_1 | |
state_topic: b2500/2/pv1/active | |
- platform: template | |
name: "D2-i11: PV 2 - Aktiv" | |
id: bool_pv_active_2_2 | |
state_topic: b2500/2/pv2/active | |
- platform: template | |
name: "D2-i02: PV 1 - Transparent" | |
id: bool_pv_transparent_2_1 | |
state_topic: b2500/2/pv1/transparent | |
- platform: template | |
name: "D2-i12: PV 2 - Transparent" | |
id: bool_pv_transparent_2_2 | |
state_topic: b2500/2/pv2/transparent | |
- platform: template | |
name: "D2-i54: Wifi Connected (?)" | |
id: bool_wifi_ok_2 | |
state_topic: b2500/2/device/wifi_ok | |
- platform: template | |
name: "D2-i55: MQTT1 Connected" | |
id: bool_mqtt1_ok_2 | |
state_topic: b2500/2/device/mqtt_ok | |
- platform: template | |
name: "D2-i58: BLE Connected" | |
id: bool_ble_ok_2 | |
state_topic: b2500/2/device/ble_ok | |
- platform: template | |
name: "D2-i21: Ausgang 1 - Aktiv" | |
id: bool_power_active_2_1 | |
state_topic: b2500/2/power1/active | |
- platform: template | |
name: "D2-i31: Ausgang 2 - Aktiv" | |
id: bool_power_active_2_2 | |
state_topic: b2500/2/power2/active | |
- platform: template | |
name: "D2-i40: Erweiterung 1 - angeschlossen" | |
id: bool_extern_connected_2_1 | |
state_topic: b2500/2/extern1/connected | |
- platform: template | |
name: "D2-i41: Erweiterung 2 - angeschlossen" | |
id: bool_extern_connected_2_2 | |
state_topic: b2500/2/extern2/connected | |
sensor: | |
- platform: template | |
name: "D1-i05: PV 1 - Leistung" | |
id: sensor_pv_power_in_1_1 | |
state_topic: b2500/1/pv1/power | |
accuracy_decimals: 0 | |
- platform: template | |
name: "D1-i15: PV 2 - Leistung" | |
id: sensor_pv_power_in_1_2 | |
state_topic: b2500/1/pv2/power | |
accuracy_decimals: 0 | |
- platform: template | |
name: "D1-i50: Füllstand der Batterie in Prozent" | |
id: sensor_bat_remain_1 | |
state_topic: b2500/1/battery/remaining_percent | |
accuracy_decimals: 0 | |
- platform: template | |
name: "D1-i51: Füllstand der Batterie in Wh" | |
id: sensor_bat_capacity_1 | |
state_topic: b2500/1/battery/remaining_capacity | |
accuracy_decimals: 0 | |
- platform: template | |
name: "D1-i25: Ausgang 1 - Leistung" | |
id: sensor_power_out_1_1 | |
state_topic: b2500/1/power1/power | |
accuracy_decimals: 0 | |
- platform: template | |
name: "D1-i35: Ausgang 2 - Leistung" | |
id: sensor_power_out_1_2 | |
state_topic: b2500/1/power2/power | |
accuracy_decimals: 0 | |
- platform: template | |
name: "A1-t59: Geräte Version" | |
id: sensor_device_version_1 | |
state_topic: b2500/1/device/fw_version | |
accuracy_decimals: 2 | |
- platform: template | |
name: "D2-i05: PV 1 - Leistung" | |
id: sensor_pv_power_in_2_1 | |
state_topic: b2500/2/pv1/power | |
accuracy_decimals: 0 | |
- platform: template | |
name: "D2-i15: PV 2 - Leistung" | |
id: sensor_pv_power_in_2_2 | |
state_topic: b2500/2/pv2/power | |
accuracy_decimals: 0 | |
- platform: template | |
name: "D2-i50: Füllstand der Batterie in Prozent" | |
id: sensor_bat_remain_2 | |
state_topic: b2500/2/battery/remaining_percent | |
accuracy_decimals: 0 | |
- platform: template | |
name: "D2-i51: Füllstand der Batterie in Wh" | |
id: sensor_bat_capacity_2 | |
state_topic: b2500/2/battery/remaining_capacity | |
accuracy_decimals: 0 | |
- platform: template | |
name: "D2-i25: Ausgang 1 - Leistung " | |
id: sensor_power_out_2_1 | |
state_topic: b2500/2/power1/power | |
accuracy_decimals: 0 | |
- platform: template | |
name: "D2-i35: Ausgang 2 - Leistung " | |
id: sensor_power_out_2_2 | |
state_topic: b2500/2/power2/power | |
accuracy_decimals: 0 | |
- platform: template | |
name: "A2-t59: Geräte Version" | |
id: sensor_device_version_2 | |
state_topic: b2500/2/device/fw_version | |
accuracy_decimals: 2 | |
- platform: ble_client | |
ble_client_id: bc2500_1 | |
internal: True | |
type: characteristic | |
name: "infoX2a" | |
id: infoX2a | |
service_uuid: 'ff00' | |
characteristic_uuid: 'ff02' | |
notify: True | |
lambda: |- | |
std::vector<char> tData; | |
for (auto b : x) { tData.push_back(b); } | |
id(ble_notify_parse).execute(1,tData); | |
return (float)x[0]; | |
- platform: ble_client | |
ble_client_id: bc2500_2 | |
internal: True | |
type: characteristic | |
name: "infoX2b" | |
id: infoX2b | |
service_uuid: 'ff00' | |
characteristic_uuid: 'ff02' | |
notify: True | |
lambda: |- | |
std::vector<char> tData; | |
for (auto b : x) { tData.push_back(b); } | |
id(ble_notify_parse).execute(2,tData); | |
return (float)x[0]; | |
### power zero - mqtt grid power sensor ( any who publish the grid power to mqtt - defined in secrets,yaml ) | |
- platform: mqtt_subscribe | |
name: "MQTT: Grid Power" | |
id: mqtt_grid_power | |
topic: !secret mqtt_grid_power | |
on_value: | |
then: | |
- script.execute: power_zero | |
###test | |
- platform: ble_client | |
ble_client_id: bc2500_1 | |
internal: True | |
type: characteristic | |
name: "infoX6a" | |
id: infoX6a | |
service_uuid: 'ff00' | |
characteristic_uuid: 'ff06' | |
notify: True | |
lambda: |- | |
std::vector<char> tData; | |
for (auto b : x) { tData.push_back(b); } | |
id(ble_notify_parse_test).execute(1,tData); | |
return (float)x[0]; | |
- platform: ble_client | |
ble_client_id: bc2500_2 | |
internal: True | |
type: characteristic | |
name: "infoX6b" | |
id: infoX6b | |
service_uuid: 'ff00' | |
characteristic_uuid: 'ff06' | |
notify: True | |
lambda: |- | |
std::vector<char> tData; | |
for (auto b : x) { tData.push_back(b); } | |
id(ble_notify_parse_test).execute(1,tData); | |
return (float)x[0]; | |
script: | |
# ble communication | |
# | |
# action ( 00f1 ) | |
# | |
# head = 0x73 | |
# length = len(paket) | |
# cntl = 0x23 | |
# cmd = 0x02 set Region 1Byte (0x00 = EU / 0x01 = China / 0x02 = Non-EU) | |
# = 0x03 runtimeInfo 1Byte (0x01) | |
# = 0x04 DeviceInfo 1Byte (0x01) | |
# = 0x0B DOD 1Byte (0-100) | |
# = 0x0C Entladeschwelle 2Byte (0-500) | |
# = 0x0D PV2-Passtrough 1Byte (0x00 on / 0x01 off) | |
# = 0x0E PowerOut 1Byte (0x00 1-2 off / 0x01 1 on / 0x02 2 on / 0x03 1-2 on) | |
# | |
# = 0x05 Wifi-Config xByte ( ssid<.,.>pwd ) | |
# = 0x08 Wifi-State 1Byte (0x01) ???? | |
# | |
# q&d c&p - more details will be added, maybe ... | |
# = 0x14 set AWS MQTT xByte ( url<.,.>Port ) .... | |
# = 0x60 set MQTT Certs xByte ( 0x00 = client.key / 0x01 = client.crt / 0x02 = ca.crt + cert len ) | |
# = 0x61 trans MQTT Certs xByte ( jeweils 128bytes des certs ) | |
# = 0x62 end MQTT Certs xByte ( ) | |
# | |
# testing / notes | |
# = 0x01 Debug ?!?! 1Byte (0x00 = off / 0x01 = on) - enables QBLEGATTSNOTIFY notify 1 / 81 ( entspricht ~ runtimeinfo ) | |
# = 0x06 | |
# = 0x07 | |
# = 0x09 | |
# = 0x0A | |
# = 0x0E HW-RESET ????? / send before head 0XAA ( deactivate output ??? ) | |
# = 0x0F new in fw 131 1Byte ( 0x01 ) | |
# | |
# = 0x30 found in logs ... unknown parm 0x01 ???? answers since fw 131 | |
# = 0x14 maybe not for mqtt ... set localtime ??? for auth/certs/challenge requests ????? ( query/set wifi depends ????) | |
# | |
# data = xx xx xx xx xx xx .... / depends on cmd | |
# crc = xor len(paket) - 1 | |
# | |
# | |
# responses ( ff02 ): | |
# | |
# head = 0x73 | |
# length = len(paket) | |
# cntl = 0x23 | |
# cmd = cmd | |
# data = xx xx xx xx xx .... | |
# | |
# | |
# | |
################ maybe direct for arm | |
# send ( ff01 ) | |
# | |
# head1 = 0xAA | |
# head2(?) = 0x55 ( not length ?!?!? ) | |
# cmd = 1x / 2x / 3x ( flash - 30 "open"/ 31 - write / 32 "close" ) / 5x | |
# data = xx xx xx xx xx .... | |
# crc = xor len(paket) -1 | |
# | |
################ maybe direct for bms | |
# send/receive ( ff06 ) | |
# | |
# head = 0xAA | |
# len = 0x05/0x03 | |
# data = xx xx xxx ( xx xx ) | |
# crc = x1 + x2 + ... + xn | |
# | |
# | |
# | |
# -> aa 05 01 00 01 01 00 08 | |
# <- aa 01 00 01 | |
# | |
# -> aa 05 01 00 01 00 00 07 | |
# <- aa 01 00 01 | |
# | |
- id: ble_command_simple | |
parameters: | |
ble_device_nr: int | |
ble_cmd: int | |
ble_cmd_parm: int | |
then: | |
- logger.log: | |
format: "ble command parse: %i [%i] %i" | |
args: [ 'ble_device_nr','ble_cmd','ble_cmd_parm' ] | |
- if: | |
condition: | |
lambda: 'return (ble_device_nr == 1);' | |
then: | |
- ble_client.ble_write: | |
id: bc2500_1 | |
#service_uuid: 'ff00' | |
#characteristic_uuid: 'ff01' | |
service_uuid: 0000ff00-0000-1000-8000-00805f9b34fb | |
characteristic_uuid: 0000ff01-0000-1000-8000-00805f9b34fb | |
value: !lambda |- | |
std::vector<unsigned char> rdat1{ 0x73,0x06,0x23,(unsigned char)ble_cmd}; | |
if (ble_cmd == 0x0C) { | |
rdat1.push_back((uint8_t)((ble_cmd_parm >> 0) & 0xFF)); | |
rdat1.push_back((uint8_t)((ble_cmd_parm >> 8) & 0xFF)); | |
} else { | |
rdat1.push_back((unsigned char)ble_cmd_parm); | |
} | |
int rlen = rdat1.size(); | |
rdat1.at(1) = rlen+1; | |
int rxor = 0; | |
for (int i=0;i<rlen;i++) { | |
rxor = rxor ^ rdat1[i]; | |
} | |
rdat1.push_back(rxor); | |
if (id(internal_console_dbg)) { | |
for (auto b : rdat1) { | |
ESP_LOGD("COMMAND", "%x - %i - %c", b,b,b); | |
} | |
} | |
return rdat1; | |
- if: | |
condition: | |
lambda: 'return (ble_device_nr == 2);' | |
then: | |
- ble_client.ble_write: | |
id: bc2500_2 | |
service_uuid: 'ff00' | |
characteristic_uuid: 'ff01' | |
value: !lambda |- | |
std::vector<unsigned char> rdat2{ 0x73,0x06,0x23,(unsigned char)ble_cmd}; | |
if (ble_cmd == 0x0C) { | |
rdat2.push_back((uint8_t)((ble_cmd_parm >> 0) & 0xFF)); | |
rdat2.push_back((uint8_t)((ble_cmd_parm >> 8) & 0xFF)); | |
} else { | |
rdat2.push_back((unsigned char)ble_cmd_parm); | |
} | |
int rlen = rdat2.size(); | |
rdat2.at(1) = rlen+1; | |
int rxor = 0; | |
for (int i=0;i<rlen;i++) { | |
rxor = rxor ^ rdat2[i]; | |
} | |
rdat2.push_back(rxor); | |
if (id(internal_console_dbg)) { | |
for (auto b : rdat2) { | |
ESP_LOGD("COMMAND", "%x - %i - %c", b,b,b); | |
} | |
} | |
return rdat2; | |
- id: ble_command_string | |
parameters: | |
ble_device_nr: int | |
ble_cmd: int | |
ble_cmd_parm: string | |
then: | |
- logger.log: | |
format: "ble command parse: %i [%i]" | |
args: [ 'ble_device_nr','ble_cmd'] | |
- if: | |
condition: | |
lambda: 'return (ble_device_nr == 1);' | |
then: | |
- ble_client.ble_write: | |
id: bc2500_1 | |
#service_uuid: 'ff00' | |
#characteristic_uuid: 'ff01' | |
service_uuid: 0000ff00-0000-1000-8000-00805f9b34fb | |
characteristic_uuid: 0000ff01-0000-1000-8000-00805f9b34fb | |
value: !lambda |- | |
std::vector<unsigned char> rdat1{ 0x73,0x06,0x23,(unsigned char)ble_cmd}; | |
for (auto b : ble_cmd_parm) { | |
rdat1.push_back((unsigned char)b); | |
} | |
int rlen = rdat1.size(); | |
rdat1.at(1) = rlen+1; | |
int rxor = 0; | |
for (int i=0;i<rlen;i++) { | |
rxor = rxor ^ rdat1[i]; | |
} | |
rdat1.push_back(rxor); | |
if (id(internal_console_dbg)) { | |
for (auto b : rdat1) { | |
ESP_LOGD("COMMAND", "%x - %i - %c", b,b,b); | |
} | |
} | |
return rdat1; | |
- if: | |
condition: | |
lambda: 'return (ble_device_nr == 2);' | |
then: | |
- ble_client.ble_write: | |
id: bc2500_2 | |
service_uuid: 'ff00' | |
characteristic_uuid: 'ff01' | |
#service_uuid: 0000ff00-0000-1000-8000-00805f9b34fb | |
#characteristic_uuid: 0000ff01-0000-1000-8000-00805f9b34fb | |
value: !lambda |- | |
std::vector<unsigned char> rdat2{ 0x73,0x06,0x23,(unsigned char)ble_cmd}; | |
for (auto b : ble_cmd_parm) { | |
rdat2.push_back((unsigned char)b); | |
} | |
int rlen = rdat2.size(); | |
rdat2.at(1) = rlen+1; | |
int rxor = 0; | |
for (int i=0;i<rlen;i++) { | |
rxor = rxor ^ rdat2[i]; | |
} | |
rdat2.push_back(rxor); | |
if (id(internal_console_dbg)) { | |
for (auto b : rdat2) { | |
ESP_LOGD("COMMAND", "%x - %i - %c", b,b,b); | |
} | |
} | |
return rdat2; | |
- id: ble_set_time | |
parameters: | |
ble_device_nr: int | |
then: | |
- if: | |
condition: | |
lambda: 'return (ble_device_nr == 1);' | |
then: | |
- ble_client.ble_write: | |
id: bc2500_1 | |
#service_uuid: 'ff00' | |
#characteristic_uuid: 'ff01' | |
service_uuid: 0000ff00-0000-1000-8000-00805f9b34fb | |
characteristic_uuid: 0000ff01-0000-1000-8000-00805f9b34fb | |
value: !lambda |- | |
std::vector<unsigned char> rdat1{ 0x73,0x0d,0x23,0x14, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3c, 0x00 }; | |
auto time = id(sntp_time).now(); | |
rdat1.at(4) = time.year - 1900; | |
rdat1.at(5) = time.month; | |
rdat1.at(6) = time.day_of_month; | |
rdat1.at(7) = time.hour; | |
rdat1.at(8) = time.minute; | |
rdat1.at(9) = time.second + 1; | |
int rlen = rdat1.size(); | |
rdat1.at(1) = rlen+1; | |
int rxor = 0; | |
for (int i=0;i<rlen;i++) { | |
rxor = rxor ^ rdat1[i]; | |
} | |
rdat1.push_back(rxor); | |
if (id(internal_console_dbg)) { | |
for (auto b : rdat1) { | |
ESP_LOGD("COMMAND", "%x - %i - %c", b,b,b); | |
} | |
} | |
return rdat1; | |
- globals.set: | |
id: ble_1_initialized | |
value: '1' | |
- if: | |
condition: | |
lambda: 'return (ble_device_nr == 2);' | |
then: | |
- ble_client.ble_write: | |
id: bc2500_2 | |
service_uuid: 'ff00' | |
characteristic_uuid: 'ff01' | |
#service_uuid: 0000ff00-0000-1000-8000-00805f9b34fb | |
#characteristic_uuid: 0000ff01-0000-1000-8000-00805f9b34fb | |
value: !lambda |- | |
std::vector<unsigned char> rdat2{ 0x73,0x0d,0x23,0x14, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3c, 0x00 }; | |
auto time = id(sntp_time).now(); | |
rdat2.at(4) = time.year - 1900; | |
rdat2.at(5) = time.month; | |
rdat2.at(6) = time.day_of_month; | |
rdat2.at(7) = time.hour; | |
rdat2.at(8) = time.minute; | |
rdat2.at(9) = time.second + 1; | |
int rlen = rdat2.size(); | |
rdat2.at(1) = rlen+1; | |
int rxor = 0; | |
for (int i=0;i<rlen;i++) { | |
rxor = rxor ^ rdat2[i]; | |
} | |
rdat2.push_back(rxor); | |
if (id(internal_console_dbg)) { | |
for (auto b : rdat2) { | |
ESP_LOGD("COMMAND", "%x - %i - %c", b,b,b); | |
} | |
} | |
return rdat2; | |
- globals.set: | |
id: ble_2_initialized | |
value: '1' | |
- id: ble_command_raw_06 | |
parameters: | |
ble_device_nr: int | |
ble_cmd_parm: char[] | |
then: | |
- logger.log: | |
format: "ble command parse (raw): %i" | |
args: [ 'ble_device_nr'] | |
- if: | |
condition: | |
lambda: 'return (ble_device_nr == 1);' | |
then: | |
- ble_client.ble_write: | |
id: bc2500_1 | |
#service_uuid: 'ff00' | |
#characteristic_uuid: 'ff06' | |
service_uuid: 0000ff00-0000-1000-8000-00805f9b34fb | |
characteristic_uuid: 0000ff06-0000-1000-8000-00805f9b34fb | |
value: !lambda |- | |
std::vector<unsigned char> rdat1; | |
for (auto b : ble_cmd_parm) { | |
rdat1.push_back((unsigned char)b); | |
} | |
/* | |
int rlen = rdat1.size(); | |
rdat1.at(1) = rlen+1; | |
int rxor = 0; | |
for (int i=0;i<rlen;i++) { | |
rxor = rxor ^ rdat1[i]; | |
} | |
rdat1.push_back(rxor); | |
*/ | |
//if (id(internal_console_dbg)) { | |
for (auto b : rdat1) { | |
ESP_LOGD("COMMAND raw", "%x - %i - %c", b,b,b); | |
} | |
//} | |
return rdat1; | |
- if: | |
condition: | |
lambda: 'return (ble_device_nr == 2);' | |
then: | |
- ble_client.ble_write: | |
id: bc2500_2 | |
#service_uuid: 'ff00' | |
#characteristic_uuid: 'ff06' | |
service_uuid: 0000ff00-0000-1000-8000-00805f9b34fb | |
characteristic_uuid: 0000ff06-0000-1000-8000-00805f9b34fb | |
value: !lambda |- | |
std::vector<unsigned char> rdat2; | |
for (auto b : ble_cmd_parm) { | |
rdat2.push_back((unsigned char)b); | |
} | |
/* | |
int rlen = rdat2.size(); | |
rdat2.at(1) = rlen+1; | |
int rxor = 0; | |
for (int i=0;i<rlen;i++) { | |
rxor = rxor ^ rdat2[i]; | |
} | |
rdat2.push_back(rxor); | |
*/ | |
//if (id(internal_console_dbg)) { | |
for (auto b : rdat2) { | |
ESP_LOGD("COMMAND raw", "%x - %i - %c", b,b,b); | |
} | |
//} | |
return rdat2; | |
- id: ble_process | |
then: | |
- if: | |
condition: | |
- lambda: 'return (id(ble_1_connected) && id(ble_1_initialized));' | |
then: | |
- script.execute: | |
id: ble_runtime_query | |
ble_device_nr: 1 | |
- script.wait: ble_runtime_query | |
### query cmd30 if firmware > 1.30 | |
- if: | |
condition: | |
- lambda: 'return (id(sensor_device_version_1).state * 100 > 130);' | |
then: | |
- script.execute: | |
id: ble_runtime_query30 | |
ble_device_nr: 1 | |
- script.wait: ble_runtime_query30 | |
- script.execute: | |
id: ble_runtime_query0F | |
ble_device_nr: 1 | |
- script.wait: ble_runtime_query0F | |
### query deviceinfo if empty | |
- if: | |
condition: | |
- lambda: 'return (id(txt_A03_1).state == "");' | |
then: | |
- script.execute: | |
id: ble_command_simple | |
ble_device_nr: 1 | |
ble_cmd: 0x04 | |
ble_cmd_parm: 0x01 | |
- script.wait: ble_command_simple | |
- if: | |
condition: | |
- lambda: 'return (id(ble_2_connected) && id(ble_2_initialized));' | |
then: | |
- script.execute: | |
id: ble_runtime_query | |
ble_device_nr: 2 | |
- script.wait: ble_runtime_query | |
### query cmd30 if firmware > 1.30 | |
- if: | |
condition: | |
- lambda: 'return (id(sensor_device_version_2).state * 100 > 130);' | |
then: | |
- script.execute: | |
id: ble_runtime_query30 | |
ble_device_nr: 2 | |
- script.wait: ble_runtime_query30 | |
- script.execute: | |
id: ble_runtime_query0F | |
ble_device_nr: 2 | |
- script.wait: ble_runtime_query0F | |
### query deviceinfo if empty | |
- if: | |
condition: | |
- lambda: 'return (id(txt_A03_2).state == "");' | |
then: | |
- script.execute: | |
id: ble_command_simple | |
ble_device_nr: 2 | |
ble_cmd: 0x04 | |
ble_cmd_parm: 0x01 | |
- script.wait: ble_command_simple | |
- id: ble_runtime_query | |
parameters: | |
ble_device_nr: int | |
then: | |
- logger.log: | |
format: "runtime query: %i" | |
args: [ 'ble_device_nr' ] | |
- script.execute: | |
id: ble_command_simple | |
ble_device_nr: !lambda return ble_device_nr; | |
ble_cmd: 0x03 | |
ble_cmd_parm: 0x01 | |
- script.wait: ble_command_simple | |
- id: ble_runtime_query30 | |
parameters: | |
ble_device_nr: int | |
then: | |
- logger.log: | |
format: "runtime query 30: %i" | |
args: [ 'ble_device_nr' ] | |
- script.execute: | |
id: ble_command_simple | |
ble_device_nr: !lambda return ble_device_nr; | |
ble_cmd: 0x30 | |
ble_cmd_parm: 0x01 | |
- script.wait: ble_command_simple | |
- id: ble_runtime_query0F | |
parameters: | |
ble_device_nr: int | |
then: | |
- logger.log: | |
format: "runtime query 0F: %i" | |
args: [ 'ble_device_nr' ] | |
- script.execute: | |
id: ble_command_simple | |
ble_device_nr: !lambda return ble_device_nr; | |
ble_cmd: 0x0F | |
ble_cmd_parm: 0x01 | |
- script.wait: ble_command_simple | |
- id: ble_powerout | |
parameters: | |
ble_device_nr: int | |
then: | |
- lambda: |- | |
int ble_cmd_t = 0x00; | |
if ( ble_device_nr == 1 ) { | |
if ( ! id(switch_powerout_1_1).state && ! id(switch_powerout_1_2).state ) { ble_cmd_t = 0x00; } | |
if ( id(switch_powerout_1_1).state && ! id(switch_powerout_1_2).state ) { ble_cmd_t = 0x01; } | |
if ( ! id(switch_powerout_1_1).state && id(switch_powerout_1_2).state ) { ble_cmd_t = 0x02; } | |
if ( id(switch_powerout_1_1).state && id(switch_powerout_1_2).state ) { ble_cmd_t = 0x03; } | |
} | |
if ( ble_device_nr == 2 ) { | |
if ( ! id(switch_powerout_2_1).state && ! id(switch_powerout_2_2).state ) { ble_cmd_t = 0x00; } | |
if ( id(switch_powerout_2_1).state && ! id(switch_powerout_2_2).state ) { ble_cmd_t = 0x01; } | |
if ( ! id(switch_powerout_2_1).state && id(switch_powerout_2_2).state ) { ble_cmd_t = 0x02; } | |
if ( id(switch_powerout_2_1).state && id(switch_powerout_2_2).state ) { ble_cmd_t = 0x03; } | |
} | |
id(ble_command_simple).execute(ble_device_nr,0x0E,ble_cmd_t); | |
if (ble_cmd_t == 0x00) { ESP_LOGD("set_power_out", "Device %i - %s", ble_device_nr,"1 OFF / 2 OFF"); } | |
if (ble_cmd_t == 0x01) { ESP_LOGD("set_power_out", "Device %i - %s", ble_device_nr,"1 ON / 2 OFF"); } | |
if (ble_cmd_t == 0x02) { ESP_LOGD("set_power_out", "Device %i - %s", ble_device_nr,"1 OFF / 2 ON"); } | |
if (ble_cmd_t == 0x03) { ESP_LOGD("set_power_out", "Device %i - %s", ble_device_nr,"1 ON / 2 ON"); } | |
- id: ble_passthrough | |
parameters: | |
ble_device_nr: int | |
switch_cmd: bool | |
then: | |
- logger.log: | |
format: "PV2 Passthrough %i : %i" | |
args: [ble_device_nr,switch_cmd] | |
- script.execute: | |
id: ble_command_simple | |
ble_device_nr: !lambda return ble_device_nr; | |
ble_cmd: 0x0D | |
ble_cmd_parm: !lambda return switch_cmd; | |
- id: ble_set_dod | |
parameters: | |
ble_device_nr: int | |
dod: int | |
then: | |
- logger.log: | |
format: "set DOD: %i" | |
args: [ 'dod' ] | |
- if: | |
condition: | |
lambda: 'return ( dod <= 100 && dod >= 10);' | |
then: | |
- script.execute: | |
id: ble_command_simple | |
ble_device_nr: !lambda return ble_device_nr; | |
ble_cmd: 0x0B | |
ble_cmd_parm: !lambda return dod; | |
- id: ble_set_discharge_treshold | |
parameters: | |
ble_device_nr: int | |
discharge: int | |
then: | |
- logger.log: | |
format: "set discharge level: %i" | |
args: [ 'discharge' ] | |
- if: | |
condition: | |
lambda: 'return ( discharge <= 500 && discharge >= 1);' | |
then: | |
- script.execute: | |
id: ble_command_simple | |
ble_device_nr: !lambda return ble_device_nr; | |
ble_cmd: 0x0C | |
ble_cmd_parm: !lambda return discharge; | |
- id: ble_notify_parse_test | |
parameters: | |
ble_device_nr: int | |
x: char[] | |
then: | |
- logger.log: | |
format: "runtime parse: %i" | |
args: [ 'ble_device_nr' ] | |
- lambda: |- | |
//if (id(internal_console_dbg)) { | |
ESP_LOGD("parse test", "x[3] = %i", x[3]); | |
for (auto b : x) { | |
ESP_LOGD("data test", "%.2x \t %i \t %c", b,b,b); | |
} | |
//} | |
- id: ble_notify_parse | |
parameters: | |
ble_device_nr: int | |
x: char[] | |
then: | |
- logger.log: | |
format: "runtime parse: %i" | |
args: [ 'ble_device_nr' ] | |
- lambda: |- | |
ESP_LOGD("notify_parse", "Device: %i", ble_device_nr); | |
if (id(internal_console_dbg)) { | |
ESP_LOGD("parse", "x[3] = %i", x[3]); | |
for (auto b : x) { | |
ESP_LOGD("data", "%.2x \t %i \t %c", b,b,b); | |
} | |
} | |
if (id(switch_debug_hexdump).state == true) { | |
ESP_LOG_BUFFER_HEXDUMP("hexdump", &x[0], x.size(), ESP_LOG_ERROR); | |
} | |
if ((std::count (x.begin(), x.end(), '_') == 16) || (std::count (x.begin(), x.begin() + 10, '_') == 3)) | |
{ | |
ESP_LOGD("main", "Data: cmd 0x0F"); | |
int pos = 0; | |
int soc = 0; | |
int t1 = 0; | |
int t2 = 0; | |
float cv = 0.0; | |
float cmin = std::numeric_limits<float>::max(); | |
float cmax = std::numeric_limits<float>::min(); | |
float ct = 0.0; | |
int found = -1; | |
char delimiter = '_'; | |
std::string xstr; | |
std::vector<float> cellV; | |
xstr.assign(x.begin(), x.end()); // copy values from vector into string xstr, deep copy | |
xstr = xstr + delimiter; // append delimiter to xstr | |
found = xstr.find(delimiter); // search for position of the first delimiter | |
while (found != -1) // loop until no more delimiter found | |
{ | |
if(pos == 0) soc = atoi( xstr.substr(0, found).c_str()); // pos 0 don't care | |
if(pos == 1) t1 = atoi( xstr.substr(0, found).c_str()); // pos 1 get int value of temperature sensor 1 | |
if(pos == 2) t2 = atoi( xstr.substr(0, found).c_str()); // pos 2 get int value of temperature sensor 2 | |
if((pos >= 3) && (pos <= 16)) // pos 3-16 parse pos for the 14 cell voltages | |
{ | |
ct = atof( xstr.substr(0, found).c_str()); // get float value of pos x | |
cellV.push_back(ct); | |
//ESP_LOGD("cell voltage", ct.c_str()); | |
cv += ct; // add actual value to var cv | |
if(ct > cmax) cmax = ct; // check for higher value as stored in cmax | |
if(ct < cmin) cmin = ct; // check for lower value as stored in cmin | |
} | |
xstr.erase(xstr.begin(), xstr.begin() + found + 1); // remove parsed string part | |
found = xstr.find(delimiter); // find next delimiter | |
pos++; // increment pos | |
} | |
/* calculate SoC from cell voltages | |
cell empty = 3.0 Volt = 0% SoC | |
cell full = 3.5 Volt = 100% SoC | |
*/ | |
// float soccalc = (cv/14000 - 3.0) * 200; | |
float lowlimit = 3.0; // low voltage limit | |
float highlimit = 3.5; // high voltage limit | |
float soccalc = 100*((cv/14000) | |
- highlimit)/(highlimit - lowlimit) + 100; // equation of line with two points (0,lowlimit) (100,highlimit) | |
ESP_LOGD("cellVoltage","soc: %i, temp1: %i, temp2: %i",soc,t1,t2); | |
ESP_LOGD("cellVoltage","cell01: %.f, cell 02: %.f, cell 03: %.f, cell 04: %.f", cellV[0], cellV[1], cellV[2], cellV[3]); | |
ESP_LOGD("cellVoltage","cell05: %.f, cell 06: %.f, cell 07: %.f, cell 08: %.f", cellV[4], cellV[5], cellV[6], cellV[7]); | |
ESP_LOGD("cellVoltage","cell09: %.f, cell 10: %.f, cell 11: %.f, cell 12: %.f", cellV[8], cellV[9], cellV[10], cellV[11]); | |
ESP_LOGD("cellVoltage","cell13: %.f, cell 14: %.f", cellV[12], cellV[13]); | |
char mtopic[48]; | |
for (int i=0; i<14; i++) { | |
snprintf(mtopic, 48,"b2500/%i/battery/cells/%02d/voltage",ble_device_nr,i+1); | |
//ESP_LOGD("cellVoltageX","%s : %f", mtopic, cellV[i]); | |
id(mqtt_client).publish(mtopic,to_string(cellV[i]/1000)); | |
} | |
snprintf(mtopic, 48,"b2500/%i/battery/cells/sum/voltage",ble_device_nr); | |
id(mqtt_client).publish(mtopic,to_string(cv/1000)); | |
snprintf(mtopic, 48,"b2500/%i/battery/cells/sum/cmin",ble_device_nr); | |
id(mqtt_client).publish(mtopic,to_string(cmin/1000)); | |
snprintf(mtopic, 48,"b2500/%i/battery/cells/sum/cmax",ble_device_nr); | |
id(mqtt_client).publish(mtopic,to_string(cmax/1000)); | |
snprintf(mtopic, 48,"b2500/%i/battery/cells/sum/cavg",ble_device_nr); | |
id(mqtt_client).publish(mtopic,to_string(cv/14000)); | |
snprintf(mtopic, 48,"b2500/%i/battery/cells/sum/cdiff",ble_device_nr); | |
id(mqtt_client).publish(mtopic,to_string((cmax-cmin)/1000)); | |
snprintf(mtopic, 48,"b2500/%i/battery/cells/sum/soccalc",ble_device_nr); | |
id(mqtt_client).publish(mtopic,to_string(soccalc)); | |
snprintf(mtopic, 48,"b2500/%i/battery/temp1",ble_device_nr); | |
id(mqtt_client).publish(mtopic,to_string(t1)); | |
snprintf(mtopic, 48,"b2500/%i/battery/temp2",ble_device_nr); | |
id(mqtt_client).publish(mtopic,to_string(t2)); | |
/* | |
id(bcsoc).publish_state(soc); // SOC from device (%) | |
id(bcsoccalc).publish_state(soccalc); // SOC calculated from cell voltages (%) | |
id(bctemp1).publish_state(t1); // Temperature 1 (°C) | |
id(bctemp2).publish_state(t2); // Temperature 2 (°C) | |
id(bccvsum).publish_state(cv/1000); // sum of cellvoltages = battery Voltage(V) | |
id(bccvmin).publish_state(cmin/1000); // lowest cellvoltage (V) | |
id(bccvmax).publish_state(cmax/1000); // highest cellvoltage (V) | |
id(bccvdiff).publish_state((cmax-cmin)/1000); | |
id(bccvavg).publish_state(cv/14000); // avarage cellvoltage (V) | |
*/ | |
} | |
else if (x[3] == 0x03) { | |
ESP_LOGD("main", "Data: runtimeInfo "); | |
//sensor | |
// pv_level 1 und 2 | |
/* | |
[6][7] PV-Eingangsleistung 1 (2Byte) | |
[8][9] PV-Eingangsleistung 2 (2Byte) | |
x[Y] | x[Z] << 8; | |
*/ | |
int pvPower1 = x[6] | x[7] << 8; | |
int pvPower2 = x[8] | x[9] << 8; | |
if (ble_device_nr==1) { id(sensor_pv_power_in_1_1).publish_state(pvPower1); id(sensor_pv_power_in_1_2).publish_state(pvPower2); } | |
if (ble_device_nr==2) { id(sensor_pv_power_in_2_1).publish_state(pvPower1); id(sensor_pv_power_in_2_2).publish_state(pvPower2); } | |
// Batterie Stand in % | |
/* | |
[10][11] Verbleibende Batteriekapazität in Prozent (2Byte) | |
x[Y] | x[Z] << 8; | |
*/ | |
int batRemain = x[10] | x[11] << 8 ; | |
if (ble_device_nr==1) { id(sensor_bat_remain_1).publish_state(batRemain / 10); } | |
if (ble_device_nr==2) { id(sensor_bat_remain_2).publish_state(batRemain / 10); } | |
// Entladen bei weniger als ??? Watt PV Eingang | |
/* | |
[19][20] Entladeschwelle(2Byte) | |
x[Y] | x[Z] << 8; | |
*/ | |
int disCharge = x[19] | x[20] << 8; | |
if (ble_device_nr==1) { id(sensor_discharge_treshold_1).publish_state(disCharge); } | |
if (ble_device_nr==2) { id(sensor_discharge_treshold_2).publish_state(disCharge); } | |
// Füllstand des Akkus in Wh | |
/* | |
[22][23] Gesamtkapazität der Batterie (1Byte) | |
x[Y] | x[Z] << 8; | |
*/ | |
int batCapacity = x[22] | x[23] << 8; | |
if (ble_device_nr==1) { id(sensor_bat_capacity_1).publish_state(batCapacity); } | |
if (ble_device_nr==2) { id(sensor_bat_capacity_2).publish_state(batCapacity); } | |
// Ausgangsleistung in Watt | |
/* | |
[24][25] Ausgangsleistung 1(1Byte) | |
[26][27] Ausgangsleistung 2(1Byte) | |
x[Y] | x[Z] << 8; | |
*/ | |
int powerOut1 = x[24] | x[25] << 8; | |
int powerOut2 = x[26] | x[27] << 8; | |
if (ble_device_nr==1) { id(sensor_power_out_1_1).publish_state(powerOut1); id(sensor_power_out_1_2).publish_state(powerOut2); } | |
if (ble_device_nr==2) { id(sensor_power_out_2_1).publish_state(powerOut1); id(sensor_power_out_2_2).publish_state(powerOut2); } | |
// Geräte Version ( Firmware ? ) | |
/* | |
[12] B2500 Geräteversion (1Byte) | |
0-255 ( ~ anzeige als /100 ) | |
*/ | |
float dev_version = x[12]; | |
if (ble_device_nr==1) { id(sensor_device_version_1).publish_state(dev_version / 100); } | |
if (ble_device_nr==2) { id(sensor_device_version_2).publish_state(dev_version / 100); } | |
// | |
/* | |
[18] Dod (1Byte) | |
0-100 Prozentualer Anteil der Entladeleistung an der Nennleistung | |
*/ | |
int dod_level = x[18]; | |
if (ble_device_nr==1) { id(sensor_dod_1).publish_state(dod_level); } | |
if (ble_device_nr==2) { id(sensor_dod_2).publish_state(dod_level); } | |
// binary sensor / bool | |
// pv 1 und 2 in | |
/* | |
[x4] PV IN 1 Zustand (1Byte) | |
[x5] PV IN 2 Zustand (1Byte) | |
0x00 (off) | |
0x01 (Aufladung) | |
0x02 (transparent für Wechselrichter) | |
*/ | |
if (ble_device_nr==1) { | |
if( x[4] == 0x00 ) { id(bool_pv_active_1_1).publish_state(false);id(bool_pv_transparent_1_1).publish_state(false); } | |
if( x[4] == 0x01 ) { id(bool_pv_active_1_1).publish_state(true); id(bool_pv_transparent_1_1).publish_state(false); } | |
if( x[4] == 0x02 ) { id(bool_pv_active_1_1).publish_state(true); id(bool_pv_transparent_1_1).publish_state(true); } | |
if( x[5] == 0x00 ) { id(bool_pv_active_1_2).publish_state(false);id(bool_pv_transparent_1_2).publish_state(false); } | |
if( x[5] == 0x01 ) { id(bool_pv_active_1_2).publish_state(true); id(bool_pv_transparent_1_2).publish_state(false); } | |
if( x[5] == 0x02 ) { id(bool_pv_active_1_2).publish_state(true); id(bool_pv_transparent_1_2).publish_state(true); } | |
} | |
if (ble_device_nr==2) { | |
if( x[4] == 0x00 ) { id(bool_pv_active_2_1).publish_state(false);id(bool_pv_transparent_2_1).publish_state(false); } | |
if( x[4] == 0x01 ) { id(bool_pv_active_2_1).publish_state(true); id(bool_pv_transparent_2_1).publish_state(false); } | |
if( x[4] == 0x02 ) { id(bool_pv_active_2_1).publish_state(true); id(bool_pv_transparent_2_1).publish_state(true); } | |
if( x[5] == 0x00 ) { id(bool_pv_active_2_2).publish_state(false);id(bool_pv_transparent_2_2).publish_state(false); } | |
if( x[5] == 0x01 ) { id(bool_pv_active_2_2).publish_state(true); id(bool_pv_transparent_2_2).publish_state(false); } | |
if( x[5] == 0x02 ) { id(bool_pv_active_2_2).publish_state(true); id(bool_pv_transparent_2_2).publish_state(true); } | |
} | |
// pv 2 durchleiten | |
/* | |
[13] Einstellung des Ladevorgangs (1Byte) | |
0x00 (PV1 Aufladung PV2 Durchleitung) | |
0x01 (Volles Laden und Entladen) | |
*/ | |
if (ble_device_nr==1) { | |
if( x[13] == 0x00 ) { id(switch_pv2_passthrough_1).turn_on(); } | |
if( x[13] == 0x01 ) { id(switch_pv2_passthrough_1).turn_off(); } | |
} | |
if (ble_device_nr==2) { | |
if( x[13] == 0x00 ) { id(switch_pv2_passthrough_2).turn_on(); } | |
if( x[13] == 0x01 ) { id(switch_pv2_passthrough_2).turn_off(); } | |
} | |
// RESERVED ( wifi / mqtt ) | |
/* | |
[15] Reserve(1Byte) | |
0x00 wifi funktioniert nicht | |
0x01 wifi ok, mqtt nicht verbunden | |
0x02 wifi ok, mqtt connect ok | |
??? 0x03 wifi ok, mqtt1 connect ok, mqtt2 connect ok | |
maybe wifi / mqtt | |
00 = false / false | |
01 = true / false | |
02 = false / true | |
03 = true / true | |
------- | |
first part means not wifi connected ?!?!? | |
00 = ??? / mqtt not connected | |
01 = ??? / mqtt not connected | |
02 = ??? / mqtt connected | |
03 = ??? / mqtt connected | |
*/ | |
// wifi and mqtt, 03 maybe webserver | |
if (ble_device_nr==1) { | |
if( x[15] == 0x00 ) { id(bool_wifi_ok_1).publish_state(false); id(bool_mqtt1_ok_1).publish_state(false); } | |
if( x[15] == 0x01 ) { id(bool_wifi_ok_1).publish_state(true); id(bool_mqtt1_ok_1).publish_state(false);} | |
if( x[15] == 0x02 ) { id(bool_wifi_ok_1).publish_state(false); id(bool_mqtt1_ok_1).publish_state(true); } | |
if( x[15] == 0x03 ) { id(bool_wifi_ok_1).publish_state(true); id(bool_mqtt1_ok_1).publish_state(true); } | |
} | |
if (ble_device_nr==2) { | |
if( x[15] == 0x00 ) { id(bool_wifi_ok_2).publish_state(false); id(bool_mqtt1_ok_2).publish_state(false); } | |
if( x[15] == 0x01 ) { id(bool_wifi_ok_2).publish_state(true); id(bool_mqtt1_ok_2).publish_state(false); } | |
if( x[15] == 0x02 ) { id(bool_wifi_ok_2).publish_state(false); id(bool_mqtt1_ok_2).publish_state(true); } | |
if( x[15] == 0x03 ) { id(bool_wifi_ok_2).publish_state(true); id(bool_mqtt1_ok_2).publish_state(true); } | |
} | |
// power 1 und 2 enabled/disabled | |
/* | |
[14] Entlade-Modus / Enabled (1Byte) | |
0x00 OUT1&OUT2 Sperren | |
0x01 nur OUT1 Freigabe | |
0x02 nur OUT2 Freigabe | |
0x03 OUT1&OUT2 Freigabe | |
*/ | |
if (ble_device_nr==1) { | |
if( x[14] == 0x00 ) { id(switch_powerout_1_1).turn_off(); id(switch_powerout_1_2).turn_off();} | |
if( x[14] == 0x01 ) { id(switch_powerout_1_1).turn_on(); id(switch_powerout_1_2).turn_off();} | |
if( x[14] == 0x02 ) { id(switch_powerout_1_1).turn_off(); id(switch_powerout_1_2).turn_on(); } | |
if( x[14] == 0x03 ) { id(switch_powerout_1_1).turn_on(); id(switch_powerout_1_2).turn_on(); } | |
} | |
if (ble_device_nr==2) { | |
if( x[14] == 0x00 ) { id(switch_powerout_2_1).turn_off(); id(switch_powerout_2_2).turn_off();} | |
if( x[14] == 0x01 ) { id(switch_powerout_2_1).turn_on(); id(switch_powerout_2_2).turn_off();} | |
if( x[14] == 0x02 ) { id(switch_powerout_2_1).turn_off(); id(switch_powerout_2_2).turn_on(); } | |
if( x[14] == 0x03 ) { id(switch_powerout_2_1).turn_on(); id(switch_powerout_2_2).turn_on(); } | |
} | |
// power 1 und 2 active | |
/* | |
[16] Ausgang Port 1 Status (1Byte) | |
[17] Ausgang Port 2 Status (1Byte) | |
0x00(Aus) | |
0x01(Entladung) | |
*/ | |
if (ble_device_nr==1) { | |
if( x[16] == 0x00 ) { id(bool_power_active_1_1).publish_state(false);} | |
if( x[16] == 0x01 ) { id(bool_power_active_1_1).publish_state(true); } | |
if( x[17] == 0x00 ) { id(bool_power_active_1_2).publish_state(false);} | |
if( x[17] == 0x01 ) { id(bool_power_active_1_2).publish_state(true); } | |
} | |
if (ble_device_nr==2) { | |
if( x[16] == 0x00 ) { id(bool_power_active_2_1).publish_state(false);} | |
if( x[16] == 0x01 ) { id(bool_power_active_2_1).publish_state(true); } | |
if( x[17] == 0x00 ) { id(bool_power_active_2_2).publish_state(false);} | |
if( x[17] == 0x01 ) { id(bool_power_active_2_2).publish_state(true); } | |
} | |
// zusatzakku 1 und 2 | |
/* | |
[28] Ist Netzgerät 1 angeschlossen (1Byte) | |
[29] Ist Netzgerät 2 angeschlossen (1Byte) | |
0x00(Kein Akkupack angeschlossen) | |
0x01(Verbinden Sie das Netzteil) | |
*/ | |
if (ble_device_nr==1) { | |
if( x[28] == 0x00 ) { id(bool_extern_connected_1_1).publish_state(false);} | |
if( x[28] == 0x01 ) { id(bool_extern_connected_1_1).publish_state(true); } | |
if( x[29] == 0x00 ) { id(bool_extern_connected_1_2).publish_state(false);} | |
if( x[29] == 0x01 ) { id(bool_extern_connected_1_2).publish_state(true); } | |
} | |
if (ble_device_nr==2) { | |
if( x[28] == 0x00 ) { id(bool_extern_connected_2_1).publish_state(false);} | |
if( x[28] == 0x01 ) { id(bool_extern_connected_2_1).publish_state(true); } | |
if( x[29] == 0x00 ) { id(bool_extern_connected_2_2).publish_state(false);} | |
if( x[29] == 0x01 ) { id(bool_extern_connected_2_2).publish_state(true); } | |
} | |
if (ble_device_nr==1) { | |
auto call_21 = id(txt_scene_1).make_call(); | |
if( x[21] == 0x00 ) { call_21.set_value("Tag"); } | |
if( x[21] == 0x01 ) { call_21.set_value("Nacht"); } | |
if( x[21] == 0x02 ) { call_21.set_value("Morgens/Abends"); } | |
call_21.perform(); | |
} | |
if (ble_device_nr==2) { | |
auto call_21 = id(txt_scene_2).make_call(); | |
if( x[21] == 0x00 ) { call_21.set_value("Tag"); } | |
if( x[21] == 0x01 ) { call_21.set_value("Nacht"); } | |
if( x[21] == 0x02 ) { call_21.set_value("Morgens/Abends"); } | |
call_21.perform(); | |
} | |
if (ble_device_nr==1) { | |
auto call_30 = id(txt_region_1).make_call(); | |
if( x[30] == 0x00 ) { call_30.set_value("EU"); } | |
if( x[30] == 0x01 ) { call_30.set_value("China"); } | |
if( x[30] == 0x02 ) { call_30.set_value("non-EU"); } | |
call_30.perform(); | |
} | |
if (ble_device_nr==2) { | |
auto call_30 = id(txt_region_2).make_call(); | |
if( x[30] == 0x00 ) { call_30.set_value("EU"); } | |
if( x[30] == 0x01 ) { call_30.set_value("China"); } | |
if( x[30] == 0x02 ) { call_30.set_value("non-EU"); } | |
call_30.perform(); | |
} | |
} | |
else if (x[3] == 0x04) { | |
ESP_LOGD("main", "Data: deviceInfo "); | |
//for (auto b : x) { | |
// ESP_LOGD("data", "%i", b); | |
//} | |
// 's<#?type=<5>,id=<24>,mac=<12>t' | |
// ESP_LOGD("data", "%s", vType); | |
int data_len = x.size(); | |
unsigned char vType[8]; | |
for (int i=9;i<14;i++) { | |
vType[i-9] = x[i]; | |
} | |
vType[5] = 0x00; | |
unsigned char vID[32]; | |
for (int i=18;i<42;i++) { | |
vID[i-18] = x[i]; | |
} | |
vID[24]=0x00; | |
unsigned char vMac[16]; | |
for (int i=47;i<59;i++) { | |
vMac[i-47] = x[i]; | |
} | |
vMac[12] = 0x00; | |
ESP_LOGD("deviceInfo", "%i: %s [%s] %s", data_len,vType,vMac,vID); | |
std::string sType(reinterpret_cast<char*>(vType)); | |
std::string sID(reinterpret_cast<char*>(vID)); | |
std::string sMac(reinterpret_cast<char*>(vMac)); | |
if (ble_device_nr==1) { id(txt_A01_1).publish_state(sType); id(txt_A02_1).publish_state(sID); id(txt_A03_1).publish_state(sMac); } | |
if (ble_device_nr==2) { id(txt_A01_2).publish_state(sType); id(txt_A02_2).publish_state(sID); id(txt_A03_2).publish_state(sMac); } | |
} | |
// get wifi info - "admin mode" only | |
else if (x[3] == 0x08) { | |
ESP_LOGD("main", "Data: wifiInfo "); | |
int data_len = x.size(); | |
unsigned char vSSID[32]; | |
for (int i=4;i<data_len-1;i++) { | |
vSSID[i-4] = x[i]; | |
} | |
vSSID[data_len-5] = 0x00; | |
ESP_LOGD("deviceInfo", "%i: %s", data_len,vSSID); | |
std::string sSSID(reinterpret_cast<char*>(vSSID)); | |
if (ble_device_nr==1) { id(txt_A11_1).publish_state(sSSID); } | |
if (ble_device_nr==2) { id(txt_A11_2).publish_state(sSSID); } | |
for (auto b : x) { | |
ESP_LOGD("data", "%x \t %i \t %x", b,b,b); | |
} | |
} | |
else if (x[3] == 0x30) { | |
ESP_LOGD("main", "Data: cmd 0x30 "); | |
int data_len = x.size(); | |
int data_pos = 0; | |
int rxor = 0; | |
for (int i=0;i<data_len;i++) { | |
rxor = rxor ^ x[i]; | |
} | |
/* | |
//if( rxor != id(cmd30_xor_last_1) ) { | |
ESP_LOGD("data 30 - raw" , "Device %i",ble_device_nr); | |
ESP_LOGD("data 30 - raw" , "0x%.2x 0x%.2x 0x%.2x 0x%.2x", x[0], x[1], x[2], x[3]); | |
for(int i=4;i<data_len-1;i++) { | |
ESP_LOGD("data 30 - raw" , "0x%.2x 0x%.2x 0x%.2x 0x%.2x 0x%.2x 0x%.2x 0x%.2x 0x%.2x 0x%.2x", x[i], x[i+1], x[i+2], x[i+3], x[i+4],x[i+5],x[i+6],x[i+7],x[i+8]); | |
i += 8; | |
} | |
//ESP_LOGD("data 30 - raw" , " "); | |
id(cmd30_xor_last_1) = rxor; | |
//} | |
*/ | |
} | |
/* | |
else if (x[3] == 0x30) { | |
ESP_LOGD("main", "Data: cmd 0x30"); | |
int data_len = x.size(); | |
for(int i=0;i<data_len;i++) { | |
int d1 = x[i]; | |
ESP_LOGD("data 30" , "%x \t %i \t %c" , d1, d1, char(d1)); | |
} | |
} | |
*/ | |
// debug ??? | |
else if (x[3] == 0x01) { | |
ESP_LOGD("main", "Data: cmd 0x01"); | |
int data_len = x.size(); | |
for(int i=0;i<data_len;i++) { | |
int d1 = x[i]; | |
ESP_LOGD("data 01" , "%x \t %i \t %c" , d1, d1, char(d1)); | |
} | |
} | |
else if (x[3] == 0x81) { | |
ESP_LOGD("main", "Data: cmd 0x81"); | |
int data_len = x.size(); | |
for(int i=0;i<data_len;i++) { | |
int d1 = x[i]; | |
ESP_LOGD("data 81" , "%x \t %i \t %c" , d1, d1, char(d1)); | |
} | |
} | |
else { | |
/*int data_len = x.size(); | |
for(int i=0;i<data_len;i++) { | |
int d1 = x[i]; | |
ESP_LOGD("unknown" , "%x \t %i \t %c" , d1, d1, char(d1)); | |
} | |
*/ | |
ESP_LOG_BUFFER_HEXDUMP("hexdump", &x[0], x.size(), ESP_LOG_ERROR); | |
} | |
- id: power_zero | |
then: | |
### Nulleinspeisung - Powerzero by neromatrix | |
### - mqtt only adaption by noone2k | |
### first attempt, use at your own risk ! | |
### Ver. 0.01m | |
- lambda: |- | |
if(id(switch_opendtu_limit).state) | |
{ | |
int ptu_min_value = 5; | |
int ptu_max_value = id(mqtt_opendtu_limit_max).state; // 50; // <- nax rel value -> id(npw2500_zeropower_max_powerlimit_rel).state; | |
int ptu_limit = 0; | |
int ptu_max_power = 900; // max:2 (x:4*2 for 4port using 2port) | |
int grid_to_ptu_ratio = ptu_max_power/100; | |
int grid_min_value = 20; | |
static int ptu_old_limit = 0; | |
/* | |
<- actual power mqtt -> prev. int(id(npw2500_grid_power).state); | |
keep over grid_min_value | |
*/ | |
int grid_value = int(id(mqtt_grid_power).state) - grid_min_value;; | |
ptu_limit = grid_value / grid_to_ptu_ratio + ptu_old_limit; | |
if(ptu_limit > ptu_max_value) ptu_limit = ptu_max_value; | |
if(ptu_limit < ptu_min_value) ptu_limit = ptu_min_value; | |
// change only if diff more than +/-1% | |
if ( ptu_limit - ptu_old_limit > 1 || ptu_old_limit - ptu_limit > 1 ) { | |
ESP_LOGD("npw2500","PowerZero PTU old limit %d, PTU new limit %d, Grid value %d " ,ptu_old_limit, ptu_limit, grid_value); | |
ptu_old_limit = ptu_limit; | |
//char mtopic[64]; | |
//snprintf(mtopic, 64,"openDTU/XXXXXXXXXXX/cmd/limit_persistent_relative"); | |
//id(mqtt_client).publish(mtopic,to_string(ptu_limit)); | |
id(mqtt_opendtu_limit).publish_state(ptu_limit); | |
} | |
} |
So hab jetzt alles vorbereitet,aber ich traue mich nicht drücken auf set MQTT local. 😂
nope ... nur 338 - 351 ... ich kann dir aber nicht sagen, was die fw 160 der v2 mit dem befehl macht. das die 160 ein equivalent der 137 ist, ist eine reine vermutung ... also auf eigenes risiko ... ( wobei ich das wahrscheinlich aus neugier auch selbst testen würde 😁 )
Kann ich dich da irgendwie unterstützen? Irgendwie Zugang zu meinen V2 Speicher geben? Was geht ist die DOD zu verstellen bei meinem V2. Cool wäre wenn ich die Ausgangsleistung anpassen könnte, das geht bestimmt auch irgendwie
@vogty79
in diesem fall reicht mir ein remote zugang nicht wirklich ...
um die kommunikation zu verstehen, benötige ich einen ble-sniff,
wenn man das mit der app einstellen kann.
bspw. m.h. von wireshark + bt5040u ( + passende firmware ) ...
einige android handy erlauben auch die kommunikation mitzuschneiden .. modellabhängig ...
oder die firmware ... da werde ich aber nicht die mir bekannten 4 wege erklären ...
ist zwar nicht illegal, aber in falschen händen könnte das problematisch werden.
wobei die falschen hände das auch so hinbekommen ...
ein ble-sniff ist die leichtere variante, als sich durch die firmware zu wühlen ...
wenn du bedenken hast, oder nicht die möglichkeit, die 160 erneut einzuspielen. kannst du das auch lassen.
alles gut 😁
wenn du auf die "wifi-steuerung" verzichten kannst, dann los 😁
theor. kannst du mit nem klick auf "werkseinstellungen laden", die mqtt server wieder gerade biegen.
bin mir da momentan aber nicht 100% sicher, müsste in die firmware schauen und ich habe nur die vom v1 ( 137 ) hier ...
// auprobieren kann/will ich gerade nicht, da ich gerade die gute sonnenzeit nutze, um die batterien zu kalibrieren
Egal,ja auf die Wifi könnte ich verzichten,ich lass es mal so.Vielleicht kommt ja doch in naher Zukunft die "offizielle" Variante für den MQTT.
Zumindest habe ich jetzt mal alles in meiner Loxone Welt wie ich es will.😉
Wenn nicht,dann werde ich mutig sein und es riskieren. 😂
Aber mal großes Danke für die ganze Arbeit hier.
@Fuxifux
alles ok ... 👍
kann nur von der v1-firmware ausgehen ... und das einzigste was da passieren kann, das mqtt nicht mehr funktioniert.
ich kann dir zu nichts raten/empfehlen, wenn ich das nicht weiss oder erfahrung damit habe ... theorie und praxis 😁
// ich bin mir immer dessen bewusst, das meine spielereien auch zu einem brick führen können
// habe auch die möglichkeit, die firmware von grund auf neu einzuspielen, was zwar nervig ist, aber fehler korrigieren kann.
// auf der anderen seite, ist das gefühl unbezahlbar, wenn es funktioniert und man was neues lernt 😁
Habt ihr einen Tip, wie man das Update des Kommunikationsmoduls einspielen kann? Ich habe das jetzt meine ich zu jeder möglichen Zeit versucht. WLAN und BT sind dabei stabil und verbunden.
Ich habe zwei V1 Speicher, die mit der 800W Entladeschwelle top funktionieren. Nur die BT-Verbindung zum ESPHome hängt sich immer mal wieder auf und dann stimmen die Statistiken nicht bzw. kann ich nicht Lastabhängig steuern.
es gibt den befehl 0x24, womit du die firmware einspielen kannst.
das ganze kann aber mehrere versuche benötigen, genauso wie in der app ...
es ist nur bequemer das ganze mit dem yaml aus dem git zu machen, als mit der app ...
falls du im photovoltaik forum bist, schreib mich dort privat an ... gleicher nick ...
// habe gerade mal getestet ... momentan dauert es bis zu 30sekunden die datei vom china-server zu ziehen ... viel zu lange ...
// ich weiss gerade nicht, ob mittlerweile das update auf den eu server umgestellt wurde ... da dauert der download < 1 sekunde ... sollte damit besser klappen ...
habe gerade gesehen, das es die fw 1.38 gibt ... gleich mal installiert ...
werde mich mal drüber hermachen, sobald es passt,
nach nem kurzen blick, sieht das erstmal nach einem bugfix release aus, aber keine neuen funktionen gegenüber der 1.37 ...
k.a. ob das was offizielles ist oder nur wieder eine interne test-version ...
also zu nachfragen bei schuss erstmal zurückhalten . bis es offiziell ist oder euch angeboten wird ...
Ja,beim V2 hab ich auch schon von einer V163 gehört. Das Pendant zum V1 wahrscheinlich.
Was echt super wäre wenn man noch die Entladeleistung einstellen könnte für den v2, dann könnte man sich eine Nulleinspeisung basteln mit zum Beispiel einen Hichi IR Sensor ohne den Umweg über den Wechselrichter zu gehen, ist ja im Prinzip nur 1 Wert der regelbar werden müsste. Der Wert wird denke ich auch nicht im eprom geschrieben da er ja mit dem zukünftigen Smartmeter auch ständig angepasst werden wird, vll kann man das in der Firmware auslesen
Im der App gibt's ja schon den Punkt Selbstanpassung. Vielleicht wurde das in den letzten Monaten der Diskussion mal erwähnt, aber gibt's nen bestimmt grund warum man die Ausgangsleistung nicht per Bluetooth einstellen kann? @noone2k
Zudem, gibts sowas wie ein Wiki zu den speichern? Derzeit gibts ja viele Infos überall verstreut.
ja, ich habe keinen v2 um zu gucken was da möglich ist und ggf. die funktionalität nachzubilden ( extrahieren und testen )
ich weiss sogut wie gar nichts über den v2, ausser was man so ab und zu nebenbei hört ( also "werbung" und aus "laien" sicht ).
im git gibt es die möglichkeit ein wiki zu nutzen ...
da schreiben nicht unbedingt meine liebste beschäftigung ist und mich von dingen abhält die mir mehr zusagen
( oder für mich wichtiger sind /höhere prios haben - wie reallife ) steht da relativ wenig bis nichts nützliches.
das ganze ist und bleibt ein hobby für mich und das bedeutet, ich nehme dinger lieber auseinander als da was zu schreiben 😁
jeder ist aber dazu eingeladen beim wiki etwas beizutragen ...
https://github.com/noone2k/hm2500pub/wiki
Ich habe ein V2.
Wie kann ich dir helfen?
Oder
Wie bekomm ich das selbst ausgelesen
Zum Thema schreiben. Kann ich Völlig verstehen 😀
habe in paar tagen die möglichkeit mir mal so ein teil genauer anzuschauen ...
verwende die ble-mac statt der serialnr ...
bzw. schaue in den mqtt-ordner im git ....
// sind das deine anfragen ? oder die vom speicher ? der speicher selbst sendet auch diese cd=01 anfragen ( an die serial - hab das schon an "schuss" weitergeleitet ... k.a. ob feature oder fehler )
// du musst diese senden, mit der ble-mac ...
// beispiele sind dort als shell scripte hinterlegt ...
Ach Du meinst ich muß erst mal ein pub machen um dann was zu bekommen 😲
jup ... du sendest den ctrl cd=01 ( mit der ble_mac ) .....
dann bekommst du auf dem sub die antwort.
aber nur für cd=01/cd=30, die anderen sind still.
den status ob die anderen funktionen funktioniert haben, kannst du wieder mit cd=01 abfragen ...
Ach Du meinst ich muß erst mal ein pub machen um dann was zu bekommen 😲
Das, was du da in deinem Screenshot siehst, ist das Topic, das die App verwendet um dem Speicher zum senden von Daten zu bringen. Der Speicher schreibt seine Nachrichten in das .../device/...
topic. Wenn du die Nachricht nicht gepublished hast, wer war das dann? 🤔 Die App schreibt doch nicht in den lokalen MQTT, oder doch?
der speicher selbst ... da das erstmal für mich auf den ersten blick keinen sinn macht, habe ich das schuss gemeldet.
aber wer weiss, warum der speicher seine daten selbst versucht abzufragen, die er sowieso schon hat ( haben müsste ) ... 😁
für die locale ansteuerung wird die ble_mac verwendet ...
//edit
@knickohr
schau dir die bash-scripte an bzw. das ocr-transcript ....
zum "lauschen": _bc2500_mqtt_listen.sh
zum "befehlen": _bc2500_mqtt_pub.sh
innerhalb der *pub.sh sind die commandos auch soweit dokumentiert.
und als kleines gimmik, ein listen parser, als reines shell-script: _bc2500_mqtt_loop.sh 😁
Hallo zusammen, ich habe heute morgen seit längerer Zeit mal wieder ein Problem. Es leuchtet die dritte Diode, was bedeutet, dass angeblich ein Update nicht sauber eingespielt wurde. Ich habe aber kein Update angestossen und benutze Version 1.3.7.
Es hilft auch kein dauerhaften Drücken der Taste, noch das abstöpseln der Module noch der Reset hinten. Bei dem Reset hinten leuchtet nur einmal kurz Power Out 2.
Hat jemand schon mal diese Situation gehabt und wie kann ich das beheben?
Ich hatte eben auch ein Phänomen mit der 137 😳
Die Batterie ist voll. Normalerweise springt der Speicher dann in den Passthrouh und schaltet PV2in direkt auf Out 2. So habe ich es jedenfalls eingestellt. Hat es aber nicht gemacht, beide Ausgämge waren zwar enabled, aber nicht aktiv. Ein erneutes setzen von Passthrouh, Out1 und Out2 hat es wiederbelebt.
Wenn das auftritt, dann den Speicher komplett stromlos machen, also sowohl In als auch Out alles abziehen. Dann ausschalten, warten bis die grüne LED am Taster aus ist, und wieder einschalten. Erst dann wieder anstöpseln.
die grüne Led (ein und Ausschalter) leuchtet nicht, nur die kleine dritte Diode.
Fehler 01 aus der FQA von Schuss
Wenn das passiert, dann den Speicher komplett stromlos machen, also sowohl In als auch Out alles abziehen. Dann ausschalten, warten bis die grüne LED am Taster aus ist, und wieder einschalten. Erst dann wieder anstöpseln.
Ich hatte das selbe Problem. Akku voll aber es wurde nichts zum wechselrichter durchgeführt. Selbst eingestellte Ausgaben von 600 Watt hat er nicht gemacht.
Hab dann die cellspannung von 3,4 auf 3,35 geändert und es lief dann.
Von euch hat nicht zufällig einer V3 und kann mir den Parameter für die Entladeleistung angeben ?
Über den Wechselrichter (openDTU) geht mir das viel zu langsam.
Zellspannung ändern ? 😳 Wie ?
@knickohr
Über die Steuerung die uns none2k gebastelt hat.
Hallo Noone2k!
Erstmal Danke für deine tolle Arbeit.
Hatte schon seit einem Monat deine Gist Version am laufen, ohne nennenswerte Probleme.
Konnte über HA alles schön steuern, Mqtt lief super.
Nun habe ich versucht deine Git Version aufzuspielen, das hat auch so weit geklappt, nur im HA verschwindet ständig die Verbindung zum ESP32. Habe in dien Version nur den API Key eingefügt. Sonst alles belassen. Über die web-Obefläche kann ich auf den ESP zugreifen.
Log kommt immer das:
API Key wieder entfernt bzw. deine Datei gar nicht verändert.
Habe den ESP komplett formatiert, , einen komplett neuen verwendet, mit Linux PC alles aufgespielt, aus HA über ESP Home alles aufgespielt, nichts fruchtet.
HA Version ist 2024.5.4
Habe nun die Gist Version wieder drauf gemacht und diese läuft sofort ohne Probleme.
Bin nicht so der große Programmierer. Bitte also um Gnade, sollte ich etwas wichtiges nicht angeführt haben.
Bitte um Hilfe.
Danke vorab
Hallo zusammen, ich habe heute morgen seit längerer Zeit mal wieder ein Problem. Es leuchtet die dritte Diode, was bedeutet, dass angeblich ein Update nicht sauber eingespielt wurde. Ich habe aber kein Update angestossen und benutze Version 1.3.7.
Es hilft auch kein dauerhaften Drücken der Taste, noch das abstöpseln der Module noch der Reset hinten. Bei dem Reset hinten leuchtet nur einmal kurz Power Out 2.
Hat jemand schon mal diese Situation gehabt und wie kann ich das beheben?
das muss nicht unbedingt der update-modus sein. in früheren software-versionen wurde mit einem bestimmten BLE-Befehl dieser Modus aktiviert.
Damit kann man u.a. den Speicher komplett resetten, neustarten und u.a. auch die firmware komplett neu enspielen.
"Maintenance-Mode" ist vllt. die bessere Bezeichung ( Wartungsmodus ).
Wenn dann der Speicher ein Update nicht abschließen konnte, verbleibt er in diesem Modus.
Wahrscheinlich wurde er deshalb "Update-Fehler", oder so, genannt.
Der kann aber auch durch andere Aktionen ausgelöst worden sein,
u.a. bei Fehlern, die das erzwingen ( welche genau, kann nur hametech beantworten ).
Anyway ... das Update verläuft momentan anders und dieser Modus wird dafür nicht mehr verwendet. ( seit ca. 1.3x )
Viel Worte für ne kurze Antwort: k.A. warum er in den "Wartungsmodus" gesprungen ist.
Da kommt man normalerweise durch sehr langes drücken , mehr als 10 Sekunden ( dürften ca. 20 sein ), wieder raus ...
Hatte erst kurzem mal wieder damit "rumgespielt".
Ich hatte eben auch ein Phänomen mit der 137 😳
Die Batterie ist voll. Normalerweise springt der Speicher dann in den Passthrouh und schaltet PV2in direkt auf Out 2. So habe ich es jedenfalls eingestellt. Hat es aber nicht gemacht, beide Ausgämge waren zwar enabled, aber nicht aktiv. Ein erneutes setzen von Passthrouh, Out1 und Out2 hat es wiederbelebt.
der speicher schaltet nur in den passthrough/transparenz modus, wenn die ausgänge deaktiviert sind,
während der die 100% erreicht.
die änderungen am modus können 3-4 minuten dauern ( jenach fw-version, bei > 1.35 sind es 4 minuten, bei <= 1.35 sind es 3 minuten) ...
steht auch in den Änderungen zu Version 1.37 dass es kein Updatemodus mehr gibt bzw. in diesen Fehler hineingesprungen wird. trotzdem habe ich das der Schuss gemeldet. Ich kann die Kiste jetzt ausschalten, allerdings springt die Kiste immer noch bei Einschalten in diesen Modus. Vielleicht behebt sich das Problem wenn die Batterie leere wird?
Ich habe ansonsten keine Idee, ich kann mich auch nicht verbinden.
Hallo Noone2k! Erstmal Danke für deine tolle Arbeit. Hatte schon seit einem Monat deine Gist Version am laufen, ohne nennenswerte Probleme. Konnte über HA alles schön steuern, Mqtt lief super. Nun habe ich versucht deine Git Version aufzuspielen, das hat auch so weit geklappt, nur im HA verschwindet ständig die Verbindung zum ESP32. Habe in dien Version nur den API Key eingefügt. Sonst alles belassen. Über die web-Obefläche kann ich auf den ESP zugreifen. Log kommt immer das:
API Key wieder entfernt bzw. deine Datei gar nicht verändert. Habe den ESP komplett formatiert, , einen komplett neuen verwendet, mit Linux PC alles aufgespielt, aus HA über ESP Home alles aufgespielt, nichts fruchtet. HA Version ist 2024.5.4 Habe nun die Gist Version wieder drauf gemacht und diese läuft sofort ohne Probleme. Bin nicht so der große Programmierer. Bitte also um Gnade, sollte ich etwas wichtiges nicht angeführt haben. Bitte um Hilfe. Danke vorab
HA ist nicht so mein steckenpferd. so gar nicht. nutze das nicht ...
für direkt HA Unterstützung, guck mal bei neromatrix vorbei: https://gist.github.com/neromatrix/6ec812f35418c4b38ebbad4e92cac888
du musst dann aber ggf. alles neu einrichten in HA. oder dir kann ggf. jmd. nen tip geben, da dort mehr erfahrung mit HA vorhanden ist.
vllt. hilft es schon den webserver komplett zu deaktivieren.
die ble-steuerung verbrät auf dem kleinen esp32 schon ne menge resourcen.
der webserver ist auch nicht ohne und dann noch HA ... ;)
ich selbst nutze nur mqtt ... ohne webserver ... mein frontend ist OH ...
neueren sachen landen im git. muss da ggf. mal aufräumen ... ist momentan nur ein sammelsurium von infos ...
müsste da mal schauen, ob paar sachen aus meiner localen version da gepusht werden könnten.
was ggf. interessant sein könnte, für leute, wie mich, deren bms sich ständigt verstellt:
- abschalten der ausgänge anhand des zellstustands ( bei mir local hardcoded, müsste parametrisiert werden )
- abschalten der ausgänge kurz vor erreichen der 100% für den passthrough( ebenfalls momentan hardcoded 😁 )
- ma gucken, was sonst noch so da habe, was man da pushen kann ...
dieses gist/git ist in erster linie für mich. teile das aber, damit andere das nutzen ( und ggf. für sich anpassen können ).
steht auch in den Änderungen zu Version 1.37 dass es kein Updatemodus mehr gibt bzw. in diesen Fehler hineingesprungen wird. trotzdem habe ich das der Schuss gemeldet. Ich kann die Kiste jetzt ausschalten, allerdings springt die Kiste immer noch bei Einschalten in diesen Modus. Vielleicht behebt sich das Problem wenn die Batterie leere wird?
Ich habe ansonsten keine Idee, ich kann mich auch nicht verbinden.
ich such dir nachher mal nen befehl raus, der den "update-modus" beendet sollte.
dabei wird aber ein reset ausgelöst.
bin erstmal ne weile afk -> küchendienst 😁
hatte den aber schonmal hier irgendwo gepostet ... brauchst dafür meine git version ...
habs aber in der aktuellen 1.38 noch nicht getestet, ob der so funktioniert ...
das Problem ist doch auch, ich kann mich mit Bluetooth nicht verbinden...dann könnte ich das auch mit der app?
in dem modus sollte auch eine bluetooth verbindung möglich sein,
vllt. nicht mit der app oder wenn das genutzte script bestimmte vorbedingungen erwartet,
die der wartungsmodus nicht liefert.
Ich habe versucht die Verbindung aufzubauen weder per App noch per Script möglich. Diese Situation hatte ich noch nicht.
schau doch mal nach, ob der Speicher überhaupt noch per Bluetooth sendet, also ob er in den Smartphone-Einstellungen zur Kopplung neuer BLE-Geräte auftaucht.
nein, jetzt gehen die Optionen aus. Ich warte auf die Rückmeldung von Schuss.
Hallo Noone2k! Erstmal Danke für deine tolle Arbeit. Hatte schon seit einem Monat deine Gist Version am laufen, ohne nennenswerte Probleme. Konnte über HA alles schön steuern, Mqtt lief super. Nun habe ich versucht deine Git Version aufzuspielen, das hat auch so weit geklappt, nur im HA verschwindet ständig die Verbindung zum ESP32. Habe in dien Version nur den API Key eingefügt. Sonst alles belassen. Über die web-Obefläche kann ich auf den ESP zugreifen. Log kommt immer das:
API Key wieder entfernt bzw. deine Datei gar nicht verändert. Habe den ESP komplett formatiert, , einen komplett neuen verwendet, mit Linux PC alles aufgespielt, aus HA über ESP Home alles aufgespielt, nichts fruchtet. HA Version ist 2024.5.4 Habe nun die Gist Version wieder drauf gemacht und diese läuft sofort ohne Probleme. Bin nicht so der große Programmierer. Bitte also um Gnade, sollte ich etwas wichtiges nicht angeführt haben. Bitte um Hilfe. Danke vorabHA ist nicht so mein steckenpferd. so gar nicht. nutze das nicht ...
für direkt HA Unterstützung, guck mal bei neromatrix vorbei: https://gist.github.com/neromatrix/6ec812f35418c4b38ebbad4e92cac888 du musst dann aber ggf. alles neu einrichten in HA. oder dir kann ggf. jmd. nen tip geben, da dort mehr erfahrung mit HA vorhanden ist.
vllt. hilft es schon den webserver komplett zu deaktivieren. die ble-steuerung verbrät auf dem kleinen esp32 schon ne menge resourcen. der webserver ist auch nicht ohne und dann noch HA ... ;)
ich selbst nutze nur mqtt ... ohne webserver ... mein frontend ist OH ...
neueren sachen landen im git. muss da ggf. mal aufräumen ... ist momentan nur ein sammelsurium von infos ... müsste da mal schauen, ob paar sachen aus meiner localen version da gepusht werden könnten. was ggf. interessant sein könnte, für leute, wie mich, deren bms sich ständigt verstellt:
- abschalten der ausgänge anhand des zellstustands ( bei mir local hardcoded, müsste parametrisiert werden )
- abschalten der ausgänge kurz vor erreichen der 100% für den passthrough( ebenfalls momentan hardcoded 😁 )
- ma gucken, was sonst noch so da habe, was man da pushen kann ...
dieses gist/git ist in erster linie für mich. teile das aber, damit andere das nutzen ( und ggf. für sich anpassen können ).
Danke. WEB Server habe ich auch schon mal rauskommentiert. Habe eine Version vom GIT aus dem März. Die habe ich damals ganz vergessen :-( . Diese läuft nun seit einer Stunde auch mit HA.
Evt. mache ich auch etwas mit diesen Einstellungen falsch:
mqtt_grid_power: "solarBatterie/powermeter/powertotal"
mqtt_opendtu_limit_state: "solarBatterie/xxxxxxxxx/status/limit_relative"
mqtt_opendtu_limit_cmd: "solarBatterie/XXXXXXX/cmd/limit_persistent_relative"
Mein OpenDTU speichert mit solarBatterie im mqqt
Sollte doch so passen, oder?
der speicher schaltet nur in den passthrough/transparenz modus, wenn die ausgänge deaktiviert sind,
während der die 100% erreicht.
Der Speicher schaltet bei 100% die Ausgänge ab um den Passthrouh zu machen ? Das sieht mir hier aber nicht so aus. Und hier hat er es meiner Meinung nach richtig gemacht. Batterie voll, direkter Passthrouh vom PV-Modul an den WR.
Ab und zu funktioniert es halt nicht. Ich hatte das glaube ich das zweite Mal, war aber ein anderer Speicher von meinen 4.
ok, da habe ich dich falschverstanden, du ungenau ausgedrückt oder einfacher gesagt: wir haben aneinander vorbeigeredet 😁 ...
anyway ...
kann mich nicht mehr 100% erinnern, wie er sich bei pv2-passthrough verhält.
nutzte pv2 passthrough auch nur mit einem ausgang ( out2 ).
wenn ich mich richtig errinnere schaltet er dann nur den out1 ab.
aber laut deinem screenshot ist dein eingang 1/2 nicht im transparenz modus ....
ist der screenshot gerade entstanden, als er umgeschaltet hat und der wechselrichter LANGSAM hochfährt ?
nutze im grunde nur noch laden/entladen und schalte die ausgänge, wie ich gerne hätte.
Ja genau, funktioniert nur mit PV2 Passthrouh. Und nein, das Foto ist von einer anderen Batterie die es korrekt gemacht hat.
Der Vorteil ist halt das es automatisch zwischen PV und Batterie umschaltet, egal ob genug vom PV kommt oder nicht. Außerdem wird so auch parallel die Batterie geladen. Andere Modi habe ich nicht ausprobiert weil das gleich so funktionierte wie ich wollte. Selbst wenn die Batterie komplett leer ist wird die Batterie erst auf 5% geladen bevor es automatisch wieder Out2 einschaltet. Kann aber auch sein das es das immer macht. Wie gesagt, es funktioniert in 99 von 100 Fällen, aber heute Morgen eben mal nicht. Keine Ahnung was dem Speicher da über die Leber gelaufen war.
DIE optimale einstellung gibt es im grunde auch nicht. kommt immer auf den einsatz zweck/"umgebung"/randbedingungen an ...
- für einige reicht eine grundlastabdeckung ... ( sinnvoll bei konstantem strompreis )
- wer tibber ( oder andere ) hat, möchte vllt. die preiskurve des lastprofils abdecken, wenn die gerade stark nach oben zeigt ...
- statt nachteinspeisung, eine tageseinspeisung, um erhöhte energiebdarf zu decken ... ( rechner, tv, console und co ) ...
oder auch ein mix aus allem, das muss jeder für sich herausfinden/entscheiden was für ihn sinnvoll ist ...
dennoch kurz: in dem screenshot ist der transparent modus nicht aktiv ( nicht am eingang ), das heisst, er nimmt in diesem fall explizit die batterie ... und die 4w deuten darauf hin, das der wr vllt. gerade angefahren ist, oder eine sehr kleine leistung eingestellt wurde.
um pv1 und pv2 transparent zu bekommen, habe ich extra einen hm1500 jetzt in benutzung , da funktioniert das gut, sonst geht mir die hälfte "verloren" ...
wenn der speicher von SoC 99% auf 100% springt schaltet er pv aus und wenn beide ausgänge zu dem zeitpunkt aktiv waren, geht er in den entlade-modus bis er auf 99% springt. und fängt dann wieder an zu laden ...
er geht nur in den transparent modus wenn zu dem zeitpunkt die ausgänge deaktiviert waren.
das mache ich momentan automatisch, in dem ich per script die ausgänge deaktiviere, sobald eine zelle vmax wert von 3.55V erreicht.
er lädt dann weiter bis 3.65 und schaltet dann automatisch transparent.
wenn ich daran denke kann ich ggf. mal gucken, wie er sich pei pt2 verhält. dürfte das gleiche sein, nur das der out1 bei mir auch auf transparenz geht, wenn dieser angeschlossen ist ...
Ich bin leider nicht weitergekommen: Alle Verbindungen gekappt und die Powertest 40 Sekunden gedrückt gehalten, nichts passiert. Es leuchtet die dritte Diode, die Power Taste leuchtet grundsätzlich nicht. Lt. Schuss sollte sich die Batterie dann wieder melden.
Dumme Frage: Was passiert, wenn die Batterie längere Zeit nicht geladen werden kann und sich ganz entlädt? Nimmt diese Schaden? Was kann ich tun, um Schaden zu vermeiden.
Batterie kommuniziert nicht und lässt sich mit Solarertrag nicht laden, zumindest zeigt sie das an.
Wie gesagt, bei mir hat es geholfen alle Verbindungen abzunehmen.
Mach doch einfach nochmal:der Büroklammerreset und dann schalte die Batterie aus und wenn dann alles dunkel ist wieder ein. Ers5 dann wieder die Araber anklemmen.
welches script läuft gerade bei dir ... und was steht bei deinem genutzten interface bei bluetooth verbindung ?
in dem modus hat die app glaube keine verbindung .... aber esp32 sollte eine aufbauen können ...
bzw. siehst du die kiste in deinem handy/tablet in der bluetooth liste ?
der Reset funktioniert nicht und wie gesagt ich kann diese nicht unter den Bluetooth Einstellungen sehen.
Nach dem Reset leuchtet kurz Power out 2 auf und dann geht diese auch aus.
und welches script verwendest du ? neromatrix oder meines ?
eine ältere Version von Dir, aber die Verbindung ist weder über Bluetooth noch über die App noch über esp32 möglich.
Meine Vermutung ist, dass die Batterien so leer sind, dass das Gerät Bluetooth abgeschaltet hat. Wie kann man jetzt die Batterie aufladen?
normalerweise sind die tips hier schon richtig gewesen ...
- 20 sekunden die taste drücken, sollte die kiste neu starten ...
- bei einigen soll wohl auch das komplette abstöpseln aller kabel geholfen haben.
im äußerten fall sollte auch der büroklammertrick helfen
( ggf. 2-3 mal machen ... pin 3-4, wenn du von hinten drauf guckst, die rechte seite wars glaube ich, müsste aber nochmal gucken)
wenn bluetooth gehen würde, könnte man auch versuchen nen befehl zum neustart zu senden.
aber ble geht nicht, laut deiner aussage.
da fällt mir auf anhieb auch erstmal nichts mehr ein.
in dieser situation war ich noch nicht, das ich mehr probieren musste.
eines der oben genannten dinge hat immer geholfen
( nicht das das öfters passiert wäre, vllt. 3-4 mal am anfang ... )
wenn schuss keine idee hat, dann hoffen das nicht soviel energy drin war
und warten bis die schaltung selbst keine energy mehr bekommt, also komplett leer ist.
und dann wieder neu aufladen ...
// edit ...
wenn selbst "schuss" nicht weiter weiss, kannst du bei deinem händler auf garantie gehen.
neu aufladen kann ich doch nur, wenn die Batterie wieder funktioniert,...
Garantie hat die Batterie, aber ich muss diese dort hin schicken...
das ist eine verzwickte Situation, weil die Batterie nicht mehr funkt...
den reset habe ich auch schon mal benutzt, das hat alles bisher funktioniert, wir kennen das ja, aber das hier ist ein bisschen anders
damit das mit dem drücken funktioniert muss die Batterie möglichst leer sein?
Es sind die beiden mittleren Pins der hinteren Buchsen. Es ist egal ob die rechte oder linke Buchse, gehen beide,
Aber zum Thema Bluetooth und leere Batterie. Es scheint tatsächlich so zu sein wenn die Batterie zu weit unten ist, dann schaltet alles ab, auch der Wikinger mit dem blauen Zahn. Hier hilft nur die PV-Module anklemmen und laden lassen. Versuche es einfach mal, laß sie ein bißchen bruzzeln. Vielleicht dann nochmal den Büroklammertrick mit nur angeklemmten Modulen. Aber wie gesagt, laß erst mal ein paar Elektronen in die Batterie rein.
Vielen Dank nochmal für eure Unterstützung.
Ich habe bei beiden Buchsen den Reset ausgelöst, aber ohne Erfolg.
Ich versuche die Batterie morgen nochmal aufzuladen.
Am Montag ist das passiert und da hing die Batterie auch an den Modulen, also rein theoretisch hätte sie da schon laden können.
Aber wir können da momentan nicht reinschauen.
Ich warte mal morgen auf Schuss, vielleicht haben die noch eine Idee.
Ich bekomme jetzt von der Schuss eine Platine mit der neuesten Version der Firmware zugeschickt. Hat das auch bereits jemand durchgeführt?
Ich gehe aber davon aus dass das dann wieder funktionieren wird, da die Firmware auf die neueste Version gehoben wird und ein Reset durchgeführt wird. Die Batterie hängt jetzt an einem Modul und die Verbindung zu WR ist gekappt.
timer beim v2 ...
[01:17:09][I][main:2689]: Data: cmd 0x13 (timer) - Device: 1
[01:17:09][I][timer:2691]: 1: 0: 0:0 - 8:45 ( 100 W )
[01:17:09][I][timer:2692]: 2: 0: 9:38 - 17:59 ( 150 W )
[01:17:09][I][timer:2693]: 3: 0: 19:27 - 24:0 ( 123 W )
jenachdem wie weit ich komme, gibt es ggf. erstmal ein kleines script am WE ( stark reduziert) für den v2 im git.
das abfragen der daten dürfte fast 1:1 zum v1 sein ...
die befehle und die logic bei den befehlen dahinter läuft anscheinend etwas anders ab. desw egen eine etwas reduzierte version.
momentan hat die kiste auch immer wieder probleme mit dem ble .... erinnert stark an die anfangszeiten mit dem v1 😁
vllt. ist auch gerade wieder ein großer rollout in planung .... und die server werden umgestellt ...
anyway, genug für heute ... ( vllt. 😁 )
//edit, sehe da fehlt noch ein byte swap ... egal, heute ist auch noch ein tag 😁
Nur zur Info,falls es jemanden hilft oder so: Schuss hat mir mitgeteilt die V163 für den V2 bald kommt und damit werden Probleme beseitigt die mit "Laden unt Entladen gleichzeitig" zusammenhängen. Auch das lokale MQTT steht kurz vor den Startlöchern.
Ich habe nen marstek und der sollte ja v2 sein mit dem geregelten Ausgang. Ich habe die V163 seit ner guten woche und mit laden und entladen habe ich probleme.
Meine Batterie wurde durch die Platine mit der Firmware 1.38 wieder Leben eingehaucht.
Bluetooth und Beladung sind wieder aktiv. Wir gehen davon aus, dass dies ein Bug in der Version 1.37 war.
Vielen Dank nochmal an das Forum und an Schuss, die aus meiner Sicht einen sehr guten technischen Support anbieten!
Weiß jemand, ob man mit der V138-Firmware für den V1-Speicher die Entladeschwelle nach wie vor problemlos über 500 erhöhen kann?
jepp ... funktioniert noch ... also das übermitteln der werte > 500 ;)
Sehr gut.
Danke für die schnelle Antwort.
Was macht dieses „enforce DOD“ genau ? Was ist der tiefere Sinn davon ?
Was macht dieses „enforce DOD“ genau? Was ist der tiefere Sinn davon?
Wieviel Kapazität in % aus dem Akku entnommen werden kann. Bei 90% bleiben Rest 10% drinn.
wenn man beim v1 nur out 1 anschließt ... und dann DOD erreicht wird, sollte theor. keine energy mehr abgegeben werden.
ABER der v1 gibt dann immer in unregelmäßigen abstanden immer wieder energy ab und der wr springt an,
wenn die ausgänge nicht abgeschaltet werden.
dafür sorgt nun "enforce_dod" ... das bei erreichen von dod auch die ausgänge abgeschaltet werden.
macht natürlich nur sinn, wenn die kiste kalibiriert ist.
man sollte da eher auf vmin von 3.0-3.1 setzen ... so ähnlich mache ich das momentan bei mir.
bei out2 passiert das nicht ...
sollte aber auch im git stehen ...
Falsch verstanden, das DOD ist klar, aber was macht dieser Schalter enforce DOD ?
OK, ist also dann bei mir belanglos da ich nur Out2 nutze und im Passthrouh geschaltet habe, vorhin hatte ich aber einen komischen Effekt : Die Batterie war rammelvoll und der Speicher hat komplett alles abgeschaltet, trotz Passthrouh. Kann aber sein das es an der V137 liegt, ist ja bekannt das die nicht so sauber funktioniert 😉 Ich werde bei Schuss mal um die 138 bitten.
Einen ähnlichen Effekt hatte ich auch genau am anderen Ende bei 2 Batterien : Beide waren komplett leer und der Speicher hat sie Transparent geschaltet statt sie bis auf 5% aufzuladen und dann wieder Out2 frei geben.
die kurve ist vavg ? ... wenn EINE zelle 3.65V erreicht, springt die anzeige auf 100% ....
wahrscheinlich auch wieder ein runner ... schau dir die einzelnen zell-werte an ...
die Kurve ist vavg? ... wenn EINE zelle 3.65V erreicht, springt die anzeige auf 100% .... wahrscheinlich auch wieder ein läufer ... schau dir die einzelnen zell-werte an ...
Ja, das war avg. MAX war eine 3,6
Habe aber nix entladen. Den ganzen Tag. Daher wunder mich es das es so weit sinkt wieder.
Das ist ganz normal, die Zelle wird bei fehlender Ladung bzw. Entladung sich immer irgendwo bei 3,3V einpendeln.
wenn du strom in eine zelle pumpst steigt die gemessene spannung ( die elektronen dichte erhöht sich an der messstelle, werden "gepresst" ) unabhängig der wirklich ladung.
sobald die ladeschlussspannung ( 3.65 ) erreicht ist, verteilen sich die elektronen gleichmäßig wieder, dürfte bei ungefähr 3.3 liegen ...
nennt sich settlement bzw. muss grad überlegen wie der fachbegriff heisst :grins:
im deutschen würde man wahrscheinlich ruhe oder verteilungs-phase sagen.
mir will partout der begriff nicht einfallen ...
anyway ... das gleiche passierte auch beim entladen ... die gemessene wert ist wesentlich niedriger ...
sobald du mit der ausspeisung stoppst ... steigt die spannung wieder leicht ... genauso umgekehrt, bei laden ... die spannung sinkt, wenn du aufhörst ...
nachdem laden sollte man theor., die kiste erstmal ne weile ruhen lassen, damit sich alles ordentlich verteilt oder akklimatisiert.
mir fallen gearde soviele synonyme ein, aber nicht der eigentlich fachbegriff ... wahrhscienlich wieder nebenbei beim kochen 😁
//edit voila: absorption 😁
Seit die v138 nun wohl für alle freigegeben wurde, führen meine beiden Speicher, angeschlossen am HM-1500 geregelt durch openDTU on battery, bei einer Leistungsabgabe nachts von ca. 35 W (das ist der minimalste Wert der Nachts immer mal wieder kurz ge- bzw. verbraucht wird) einen Reset durch, der das kalibrierte BMS wieder "zerstört", Einstellungen wie DoD, der Entladeschwelle und Laden vor Entladen, bleiben so wie eingestellt.
Das passiert aber nur, wenn Out1 oder Out1/2 offen sind. Wenn nur Out2 offen ist, lässt sich dieser "Bug" nicht feststellen. Bei v135 passierte das nicht. Kann auch nicht sagen, ab wieviel Watt das genau geschieht und ob das auch Auftritt, wenn an den Eingängen wieder Strom anliegt.
Gibt es ne unkomplizierte Möglichkeit wieder v135 einzuspielen? Mail an schuss.at geht noch raus...
edit: manchmal scheint der Speicher "nur" einen Neustart zu machen ohne das BMS zurückzusetzen...
Jetzt waren ca. 250W an den Eingängen, bei 20W an Out1 kam der Neustart und ab da zeigte die App 60W an den Eingängen an - Out1 deaktiviert, Eingänge blieben bei gleicher Leistung - Neustart - Eingänge wieder normale Anzeige...
@mikerway Das Verhalten hatte mein Speicher auch schon mit 1.35
Dann springt der Füllstand meistens 20% nach oben und der Speicher entlädt wieder komplett.
Ausserdem schaltet er nach Belieben mal den Out2 ab und bleibt dann bei der Einstellung "Out 1 an, Out 2 aus".
Schuss.at hat mir die v135 freigegeben und nun funktioniert es wieder, also bei geringem Verbrauch und mit beiden Ausgängen, bzw. nur Out1 offen -> kein Reset/Neustart!
@andreash-esp
Es ist bei mir mit der v135 nur einmal vorgekommen, das ein Speicher einen Reset gemacht hat, ansonsten liefen die einwandfrei. Deshalb ist es mir wichtig, dass beide Ausgänge offen sind, so kann man im Vorbeigehen (die stehen im Hausflur) sehen, ob es Probleme gab...
@mikerway wo hast du da hin geschrieben meine Speicher machen auch nicht mehr das was sie mal gemacht haben. Bei V135 lief alles top
@mikerway wo hast du da hin geschrieben meine Speicher machen auch nicht mehr das was sie mal gemacht haben. Bei V135 lief alles top
service-home@schuss.at
mit der Angabe der E-Mail-Adresse mit der du in der App angemeldet bist.
Gibts vielleicht schon Neuigkeiten zum v2 wie man da die Leistung verstellen kann?
Ähm - ist es sinnvoll sich (noch) einen V1 - Speicher zu holen?
Daran betreiben möchte ich einen Hoymiles 1600 mit dynamischer Regelung via OpenDTU on Battery ...
Danke!
ich persönlich bevorzuge momentan (noch ?), den v1 mit opendtu ...
für mich ist es noch zu früh da eine empfehlung abzugeben.
genau wie beim v1, muss man die macken und eigenarten des v1.2 erstmal verstehen,
um damit vernünftig umgehen zu können um das beste ( für sich ) rauszuholen.
wenn du mit dem wechselrichter arbeiten willst, tendiere ich momentan eher zur v1.
kann aber daran liegen, das ich noch zu wenig beim v1.2 weiss und noch alles zu neu ist.
man neigt ja dazu, liebgewonnenes und funktionierendes nicht zu schnell aufzugeben 😁
//edit ... wenn du bspw. am hm noch module dran hast, könnte es sinnvoller sein einen v1.2 zu nutzen.
dann kann man den wr auf 100% laufen lassen ... und den speicher ( selbst geregelt ) zu zuschalten, wenn die module nichts mehr
oder weniger liefern als gebraucht wird.
nur mal so als idee in die runde geworfen ;) nicht getestet ...
Hallo,
ich habe versucht von Neonmatrix seiner Version auf diese umzusteigen da ich mir demnächst einen zweiten Speicher holen möchte und auch eventuell die V1.2 Regeln möchte. Leider bekomme ich immer folgende Fehler. Bei Neonmatrix seiner HA Version läuft alles Problemlos.
`13:41:24][W][ble_sensor:123]: [infoX2b] Cannot poll, not connected
[13:41:28][W][ble_sensor:123]: [infoX2a] Cannot poll, not connected
[13:42:12][W][web_server_idf:070][httpd]: Only application/x-www-form-urlencoded supported for POST request
[13:42:14][I][esp32_ble_client:067]: [0] [E8:8D:A6:F3:62:17] 0x00 Attempting BLE connection
[13:42:14][W][web_server_idf:070][httpd]: Only application/x-www-form-urlencoded supported for POST request
[13:42:14][I][ble_sensor:031]: [infoX2a] Connected successfully!
[13:42:15][I][esp32_ble_client:227]: [0] [E8:8D:A6:F3:xx:xx] Connected
[13:42:16][I][main:2696]: ble command send: 1 [2] 0
[13:42:22][I][esp-idf:000][wifi]: I (289692) wifi:
[13:42:22][I][esp-idf:000][wifi]: bcn_timeout,ap_probe_send_start
[13:42:22][I][esp-idf:000][wifi]:
[13:42:24][W][ble_sensor:123]: [infoX2b] Cannot poll, not connected
[13:42:28]handle error: do nothing :)
[13:42:28][W][ble_sensor:078]: Error reading char at handle 21, status=2
[13:42:33][I][ota:117]: Boot seems successful, resetting boot loop counter.
[13:42:48][I][esp-idf:000][wifi]: I (315951) wifi:
[13:42:48][I][esp-idf:000][wifi]: bcn_timeout,ap_probe_send_start
[13:42:48][I][esp-idf:000][wifi]:
[13:43:20][I][esp-idf:000][wifi]: I (347480) wifi:
[13:43:20][I][esp-idf:000][wifi]: bcn_timeout,ap_probe_send_start
[13:43:20][I][esp-idf:000][wifi]:
[13:43:24][W][ble_sensor:123]: [infoX2b] Cannot poll, not connected
[13:43:28]handle error: do nothing :)
[13:43:28][W][ble_sensor:078]: Error reading char at handle 21, status=2d`
ist schone ne weile her, aber wenn ich mich richtig erinnere, dürfte der fehler im zusammenhang mit dem webinterface stehen ...
das nutze ich schon ne weile nicht mehr und local bei mir ist dieser auch deaktiviert ...
zur steuerung am besten nur mqtt nutzen ...
wenn das deaktivieren des webservers nichts bringt, den esp32 einmal mit "esptool erase_flash --port " komplett löschen ...
du kannst auch vorher ein erase_flash probieren ...
@noone2k danke für deine Hilfestellung. Ich habe nun den Webserver rauskommentiert und 3 neue ESP s getestet. Bei keinem hatte ich Erfolg. Was mich stutzig macht ist das sobald ich den ESP an habe auch nicht mit dem Smartphone per APP drauf komme. Das heist ja dann das hier eine Theoretische Verbindung besteht.
ja, die ble verbindung steht laut log.
scheint aber probleme mit dem wifi bei dir zugeben ...
du kannst noch versuchen den ap bzw. captive portal rausnehmen ...
so sieht das ungefähr bei mir local aus ...
# Enable fallback hotspot (captive portal) in case wifi connection fails
#ap:
# ssid: "Bc2500-Ble Fallback Hotspot"
#web_server:
# port: 80
#ota: false
#js_include: "./v3/www.js"
# js_include: "./v2/www.js"
# local: true
# js_url: ""
# version: 2
#captive_portal:
wenn klappt, nehme ich das generell raus ...
der webserver war ein schönes vehikel für den anfang und manchmal ganz praktisch :)
ggf. mal prüfen wenn nur ap/captive deaktiviert ist, ob es klappt ...
// in der b2500v2 version ist das schon deaktiviert, da lass ich das dann auch erstmal ...
bin leider etwas unerwartet seit paar tagen leicht im stress und im privaten umfeld mehr gefordert ...
sieht für die nächsten tage nicht besser aus ...
damit ihr nicht länger warten müsst, pack ich mal die b2500v2 yaml nachher ins git, so wie sie ist.
vllt. noch das eine oder andere aufräumen und rausnehmen ....
die liegt schon ne weile hier rum und ist noch nicht 100% fertig und sauber ... u.a. die 2 kisten steuerung fehlt
aber die grundsätzlichen sachen sollten funktionieren ...
- auslesen der daten
- timer 1/2/3 an/aus
- sowie das setzen der power ( über timer 3 ).
die ausgänge kann man beim v2 nicht mehr gezielt ein/aus schalten.
das geschieht momentan durch die automatische regelung bzw. über die timer ...
bin mir noch nicht sicher ob mir das gefällt, habe lieber mehr kontrolle über das system.
aber für die einfache anwendung beim "endkunden" ist das sicherlich ein fortschritt,
wenn er sich nicht im detail um alles kümmern muss/will.
Hey noone2k,
habe nun meinen ESP aus dem Wlan in ein anderes genommen da scheint es besser zu gehen. Mein IOT Wlan scheint wohl etwas zu blocken. Ich versteh nicht warum da bis jetzt alle Geräte auch mit MQTT etc. funktionierten. Nun habe ich aber folgenden Fehler.
Das rauskomentieren des Webservers etc. hatte keine Veränderung gebracht.
[17:21:20][W][component:237]: Component esp32_ble took a long time for an operation (53 ms).
[17:21:20][W][component:238]: Components should block for at most 30 ms.
[17:21:25][I][main:2696]: ble command send: 1 [15] 1
[17:21:25][I][main:1774]: runtime parse: 1
[17:21:25][I][cellVoltage:1842]: soc: 99, temp1: 27, temp2: 28
[17:21:25][I][cellVoltage:1843]: cell01: 3346, cell 02: 3345, cell 03: 3346, cell 04: 3343
[17:21:25][I][cellVoltage:1844]: cell05: 3346, cell 06: 3345, cell 07: 3346, cell 08: 3347
[17:21:25][I][cellVoltage:1845]: cell09: 3345, cell 10: 3347, cell 11: 3346, cell 12: 3346
[17:21:25][I][cellVoltage:1846]: cell13: 3346, cell 14: 3344
[17:21:25][W][component:237]: Component esp32_ble took a long time for an operation (68 ms).
[17:21:25][W][component:238]: Components should block for at most 30 ms.
In meinem Broker erscheint folgendes
2024-05-30 17:11:35: New client connected from 192.168.178.154:56607 as bc2500-ble-idf-c82e18228aa4 (p2, c0, k15, u'mqtt_esp').
2024-05-30 17:11:40: New connection from 192.168.178.193:57421 on port 1883.
Aber in meinem MQTT-Homeassistant wird kein bc2500xxx angezeigt.
@azazul1980
die warnung mit dem blocken, kannst du ignorieren ...
dieses yaml nutzt eine reine mqtt-anbindung in dein smarthome-system.
es gibt keine direkte HA unterstützung und du musst die mqtt topics selbst anlegen
ODER
du kannst probieren, mqtt discovery zu aktivieren ... das sollte auch von HA verstanden werden ....
//edit in dem yaml:
von
discovery: False
auf
discovery: True
ändern ... in der mqtt section
So ich hab nun auf Disovery True umgestellt und die neue V2 Version in der Hoffnung das es eventuell gleich lauft ;0) na ja jetzt sind es wieder andere Probleme
INFO Starting log output from b2500v2/debug
INFO Connected to MQTT broker!
[18:18:55][I][esp-idf:000]: I (760217) MQTT_CLIENT: Client asked to disconnect
[18:19:07][W][component:170]: Component mqtt cleared Warning flag
[18:19:07][I][mqtt:274]: MQTT Connected!
[18:19:09][I][app:062]: setup() finished successfully!
[18:19:09][W][esp32_ble_tracker:110]: Too many BLE events to process. Some devices may not show up.
[18:19:09][I][app:100]: ESPHome version 2024.5.4 compiled on May 30 2024, 18:12:32
[18:19:11][I][esp-idf:000][wifi]: I (10544) wifi:
[18:19:11][I][esp-idf:000][wifi]: idx:1 (ifx:0, 72:a7:41:a1:cd:50), tid:5, ssn:1, winSize:64
[18:19:11][I][esp-idf:000][wifi]:
[18:19:11][I][esp-idf:000][wifi]: I (10623) wifi:
[18:19:11][I][esp-idf:000][wifi]: idx
[18:19:11][I][esp-idf:000][wifi]:
[18:19:11][I][esp-idf:000][wifi]: I (10628) wifi:
[18:19:11][I][esp-idf:000][wifi]: idx
[18:19:11][I][esp-idf:000][wifi]:
[18:19:11][I][esp-idf:000][wifi]: I (10656) wifi:
[18:19:11][I][esp-idf:000][wifi]: idx:0 (ifx:0, 72:a7:41:a1:cd:50), tid:0, ssn:52, winSize:64
[18:19:11][I][esp-idf:000][wifi]:
[18:19:27][I][main:3096]: ble command send: 1 [0x0F] 1
[18:19:27][W][ble_client.automation:141]: Cannot write to BLE characteristic - not connected
[18:19:28][I][main:3096]: ble command send: 1 [0x13] 0
[18:19:28][W][ble_client.automation:141]: Cannot write to BLE characteristic - not connected
[18:19:32][I][main:3096]: ble command send: 1 [0x0F] 1
[18:19:32][W][ble_client.automation:141]: Cannot write to BLE characteristic - not connected
die ble_mac in der secret eingetragen ( hm2500_3_mac: ) ?
Ja hab ich gemacht.
Hab nur einen Speicher deswegen gleich bei allen 4 und einmal hab ich es mit Fake Mac Adressen versucht hat leider auch nicht funktioniert.
hm2500_1_mac: "E8:8D:A6:F3:62:17"
hm2500_2_mac: "E8:8D:A6:F3:62:17"
hm2500_3_mac: "E8:8D:A6:F3:62:17"
hm2500_4_mac: "E8:8D:A6:F3:62:17"
adressen nicht doppelt eintragen ...
beim v2 script wird nur 3/4 genutzt ...
besteht von einem anderem gerät schon eine verbindung ?
was mich interessiert: hast du herausgefunden was an deinem iot netzwerk anders ist ?
sowas verschlüsselung oder modis ? passwort mit sonderzeichen oder ähnliches ?
ich habe leider nicht herausgefunden was in dem iot Netzwerk anders ist habe aber auch nicht mehr danach geforscht werde ich aber in den nächsten Tagen. Nachdem ich nun mqtt True und die die Mac auf hm2500_3_mac gesetzt habe funktioniert es nun. Und ich muss sagen sogar bis jetzt sehr gut. Ich würde auch gerne neonmatrix seine Lösung mit dem WR zur Regulierung rausschmeißen habe aber angst das evtl. der EPROM von dem Accu nach einiger Zeit evtl über den Jordan geht bei alle 10 sek der Wertveränderung. Was meinst du noone2k wird hier der nicht persistente Speicher beschrieben ?
habe aber angst das evtl. der EPROM von dem Accu nach einiger Zeit evtl über den Jordan geht bei alle 10 sek der Wertveränderung. Was meinst du noone2k wird hier der nicht persistente Speicher beschrieben ?
pack mal hier oben eine kurzantwort rein: eine nulleinspeisung würde ich momentan damit nicht realisieren. da weiss ich zu wenig.
konnt noch nicht sehen, wo die daten gespeichert werden ....
aber der v2 scheint nen eigenständiges rtc zu haben ( mit knopfzelle ) ...
die meisten rtc besitzen neben der eigentlichen funktion ( nämlich einer realtime clock ) auch nen kleinen speicher für zusatzdaten.
und wenn wirklich ALLE daten, die mit der timer funktion zu tun haben dort landen,
sehe ich da erstmal kein problem ... kommt aber auf den verwendeten rtc-chip bzw. technik an ...
sollte ein rtc verwendet werden mit eprom , sollte man keine nulleinspeisung damit realisieren.
bei fram oder vergleichbare techniken sollte das kein problem sein ...
sagen wir mal so: es steht 50:50, das es nicht im flash landet, sondern im rtc gehalten wird ...
da müsste man mal bei schuss nachfragen, ob es ne auskunft gibt, wo die timerdaten landen ...
diese timer lösung für die einspeise steuerung ist nur ein workaround ...
ich gehe davon aus das die ct001 lösung ( smartmeter ) nicht dauerhaft irgendwo speichert,
sondern eine ECHTE runtime regelung hat.
da ich aber momentan keinen ct001 hier habe, kann ich dazu weder was über die technik noch den ablauf sagen.
dürfte aber ( rein theor. ) die bessere lösung sein, als der timer-workaround ...
Danke für deine Einschätzung. Dann werde ich erst einmal warten.
@noone2k wie kann ich eigentlich das Zeitprofil bzw. den Zeitraum über den ESP ändern ? Ich habe leider das Verhalten das bei einer nulleinspeissung nach 1-2 Stunden haut es mir die Zeit raus.
Update: habe noch einmal mein IOT Netzwerk angeschaut und den ESP wieder Connected . Alles ok es war wohl wirklich das MQTT Problem mit dem True oder der BLE Mac ab Profil 3.
Doofe Frage, die neuste Version ist immer die oben abgebildete? Wo finde ich die aktuelle Secrets?
@gine78 https://github.com/noone2k/hm2500pub
Hier gibt's die aktuelle Version. Und auch ein paar Infos.
@gine78 https://github.com/noone2k/hm2500pub Hier gibt's die aktuelle Version. Und auch ein paar Infos.
Danke!
läuft bei mir auch soweit mit dem v2, danke @noone2k
Eine bedarfsgerechte Einspeisung mit einem Tasmota Sensor wäre jetzt noch das i Tüpfelchen, aber mal sehen was noch kommt in der Zukunft, werde mir aber wahrscheinlich das Smartmeter besorgen sobald es auf dem Markt ist (laut Schuss so Juli-August)
@noone2k ich hatte da echt ein Brainlag, ich hab dein github sogar schon "Stared" xD
Ich habe mal mal den HErsteller des Speichers angeschrieben (das kann man ganz gut über die Power Zero App, Anfragen darüber landen in China.)
Auf die Frage, wo die Daten der Zeitsteuerung gespeichert wird, kam als Antwort:
Hallo. Es wird in EPROM beschrieben. Mit freundlichen Grüßen.
Wenn jetzt jede Änderung der Ausgangsleistung in ein EProm geschrieben wird, ist es absehbar, dass dieser kaputt geht. Auf die Frage, wie es dann mit dem "CT100" funktionieren wird, kam "Hallo. Wir können dazu keine näheren Angaben machen. Wir danken Ihnen für Ihr Verständnis. Einen schönen Tag noch!
"
Hat jemand Kontakte zu Schuss? Mich würde das wirklich interessieren, da ich mir eigentlich nicht vorstellen kann, dass das ein Eprom mit diesen Daten beschrieben wird. Das ist ja quasi eine tickende Zeitbombe.
Habe bei Schuss angefragt mal sehen was die antworten
für normale nutzung der timer funktion, die man nicht alle 10 sekunden ändert , reicht die durchscnittliche haltbarkeit jahrzehnte.
da macht eher ne zelle schlapp.
problematisch kann es nur werden, wenn man da wirklich alle 10 sekunden neue werte reinschreibt.
bei nem durchschnittlichen wert von 1.000.000 ... und 10 sekunden ... 1.000.000 / ( 6 * 60 * 24 ) ~ 115 tage .... also knapp 4 monate ...
aber so ein teil kann schon vorher versagen oder auch sehr sehr viel später ...
und wie gesagt, beim smartmeter gehe ich stark davon aus, das die werte NICHT ( wüsste gerade nicht aus welchen grund ) gespeichert werden, sondern direkt zur aussteuerung gehen.
@noone2k wie kann ich eigentlich das Zeitprofil bzw. den Zeitraum über den ESP ändern ? Ich habe leider das Verhalten das bei einer nulleinspeissung nach 1-2 Stunden haut es mir die Zeit raus.
für das editieren der zeiten, habe ich noch keine gesonderte funktion.
was man relativ schnell einbinden könnte, wäre das feste schreiben von 00:00-24:00 bei timer 3 ...
hatte das gestern auch kurz auf dem schirm ...
wie aber kurz angedeutet, bin ich gerade privat anderweitig gefordert ...
Alles klar @noone2k kein Stress 😜. Danke für deine Bemühungen.
Ich habe einen V2 mit der Firmware 1.63. Ich bekomme weder mit der ursprünglichen hm2500pub noch mit der angepassten Version für den V2 den Output der Batterie angezeigt, so wie er in der App zu sehen ist.
Erwarten würde ich den Output über dieses Topic: b2500v2/1/power/power.
In der Nacht, so kurz vor erreichen der Entladegrenze erhalte ich Daten für ca. ~1 h.
Woran könnte das liegen?
Ach ja, heute morgen ist die Version für den V2 auf Git verschwunden!?
@Reinschki die ist noch da: https://github.com/noone2k/hm2500pub/blob/master/config/b2500-v2-ble-idf.yaml
und ja, das Topic stimmt.
Was sagt denn das Log? Ist er verbunden, oder verbindet sich ein Smartphone oder so?
Hm, stimmt ist (wieder) noch da. War wohl zu früh, heute morgen ;-)
Das mit dem Log funktioniert ja nur wenn der ESP per Kabel angeschlossen ist, Oder?
Also, ich stelle "Laden vor dem Entladen" in der App ein. Ich habe laut App Input und Output gleichzeitig.
MQTT liefert den Input und aktualisiert auch. Der Output bleibt bei 0 oder manchmal geht er auch auf den Wert 1. Und das obwohl die App viel höhere Werte anzeigt.
an das runtime log, ohne kabel, kommst du bspw. mit
mosquitto_sub -h <BROKER_IP> -t b2500v2/debug
der bootlog ist da natürlich nicht mit bei ...
und ja in power/power sollte die summe aus beiden outputs ( power[1|2]/power ) drin stehen ...
Habe gelesen, dass man sich mqtt freischalten lassen kann, dann braucht man den Umweg über den esp doch eigentlich nicht mehr?
richtig ...
die meisten grunddaten und -funktionen können damit abgerufen/ausgeführt werden ...
reicht auch für das wichtigste ...
könnte auch die stabilität erhöhen ...
du musst dann nur alle Daten in deinem Smarthome-System parsen und die Funktionen abbilden ...
dürfte für einige sogar angenehmer sein, wenn man sich mit seinem "lieblings"-system sehr gut auskennt,
als den umweg über ein esp32 , wenn dieser neuland für einen ist ...
//edit ...
u.a. ist der vorteil des esp32 momentan der abruf der zellinfos und die damit verbundenen möglichkeiten,
auf bestimmte zellzustände zu reagieren.
Wie kann man sich mqtt freischalten lassen?
kommentarfunktion in der app, eine email an schuss oder m.h. des esp32 ( einrichten ) ...
mit der freischaltung und EINRICHTUNG des lokalen mqtt ist der app-support aber eingeschränkt.
mit der app geht dann nur noch bluetooth ( und theor. noch die statistiken ) ...
fernsteuerung per app ( "wifi-steuerung" ) geht dann nicht mehr.
für die fernsteuerung kannst du aber vpn oder ähnliches benutzen ( einige smarthome-systemen bieten ja ne eigene cloud ).
kleiner nachtrag ... zum mqtt ...
die "freischaltung" betrifft die funktion, das man sich m.H. der App die möglichkeit zur Einrichtung des lokalen mqtt freischalten kann.
die einrichtung selbst kann man aber auch mit dem esp32 selbst machen.
Zusätzlich zur "Freischaltung" zeigt die app dann auch ein Online-Manual an.
eine ocr-transcription ist im mqtt-ordner des gits enthalten. ( falls man m.h. des esp32 die einrichtung vornimmt )
wie bei ocr üblich mit erkennungsfehlern, korrekturen/ergänzungen sind willkommen ;)
update v2 script ...
- some cosmetics
- preparation 2nd device support
- bms-fix to prevent total-discharge ( untestet )
- set fixed times for timer 3
- maybe some others ...
more info: https://github.com/noone2k/hm2500pub/commits/master/
mal ne frage in die runde ... hatte jmd überhaupt schonmal ein bms reset bei dem v2 ?
@noone2k ich habe die neue Version installiert und es scheint alles zu laufen. Was ich nicht verstehe ist das BMS Reset beim V2 war das einmal ein Problem ? Bei mir ist es leider passiert beim versuch über den Accu die Stärke zu regeln regelmäßig der Timer rausgeflogen ist. War das evtl. ein BMS Reset ?
sry, war ich zu ungenau ... mit bms reset meinte ich in diesem zusammenhang, das der akku die kalibrierung "vergisst",
was bei meinem v1 ja gerne mal passiert. dann ist bspw. die einstellung "DOD" sinnlos, weil er ja nicht weiss,
wieviel noch in der Kiste drin ist.
da ich nicht "immer" neu kalibrieren wollte, hatte ich beim v1 bei mir einfach im script gesagt: schalte die ausgänge aus, sobald ne zelle unter 3.1V rutscht.
diese funktion ist jetzt bei der v2 adaptation im script dringeblieben.
musste nur ein wenig die funktionsweise ändern, da man die ausgänge nicht mehr direkt ansteuern kann.
mal sehen, ob es reicht, einfach die timer zu deakvieren.
mir ist dann im nachhinein eingefallen, das ich bisher ( toi toi toi ) beim v2 gar keine bms-resets hatte und nicht neu kalibrieren musste 😁
was meinst du mit timer rausgeflogen ? alles genullt ?
//edit
btw. wenn da wirklich ein rtc mit eprom drin ist ( gespeist durch eine knopfzelle ),
könnte man theor. , wenn der speicher gross genug ist, darin die kalibrierungsdaten spiegeln
und bei einem reset einfach wieder einspielen.
vllt. wird das auch gemacht und deswegen sind mir keine resets aufgefallen, bisher.
habe aber auch ehrlich noch nicht alle stastiken bei mir wie beim v1 eingerichtet, so das ich das alle erkennen kann.
Hallo zusammen,
ich habe gestern über die Feedback Option der App diese Frage gestellt:
Ist es möglich Informationen per MQTT vom Batteriespeicher zu erhalten und diesen über ein eigenes Smarthome System zu steuern?
Diese Antwort kam heute (genau so) per Mail:
Hallo Reiner! B2500 unterstützt nur das öffnen des MQTT-Protokolls für selbst erstellte Broker von den Professionellen und nicht das öffnen für Broker von Drittanbietern. Und wir werden die technische Unterstuetzung stoppen, nachdem das MQTT-Protokoll für Sie geöffnet wurde. Stellen Sie also bitte sicher, dass Ihr Gerät keine Probleme mehr hat. Dies ist auch für den Schutz der Benutzerinformationen, bitte verstehen. Prüfen Sie daher bitte noch einmal, ob Sie die MQTT-Berechtigung aktivieren wollen. Mit freundlichen Grüßen.
Hat da jemand von Euch Erfahrung damit gesammelt?
Sind die Topics und der Payload zum Steuern bekannt?
Erhalte ich dann noch Firmware Updates?
Komme ich ggf. wieder zurück?
Für mich ist die Mail schwer zu verstehen. Ich denke eine vertiefende Nachfrage über die Feedback Funktion der App wird möglicherweise auch nicht erhellender sein.
Deshalb ertmal die Frage an die Experten hier!
VG Reiner
ocr-transcript des online-manuals: https://github.com/noone2k/hm2500pub/blob/master/mqtt/mqtt_diz.txt
fw-updates sind weiterhin möglich, da diese per http und bluetooth ( direkt über die app ) geschehen.
mit der funktion "grundeinstellungen wiederherstellen" ( oder so ähnlich ),
werden wieder die amazon-mqtt server genutzt.
das stoppen der technischen unterstützung bezieht sich wahrscheinlich nur auf die möglichkeit die kiste remote zu steuern etc.,
da dann die app /hametech nicht mehr die möglichkeit hat selbst per mqtt "remote" darauf zuzugreifen kann ... ( just guessing )
eine lokale ble steuerung ist weiterhin möglich ( app oder esp32 )
Ok, aber was ist denn der Vorteil von der Freischaltung des MQTT? Ich sehe aktuell, dass ich doch einen größeren Vorteil habe, wenn ich das über die Amazon Cloud und den ESP laufen lasse als wenn ich das über eine lokale laufen lasse?
wenn du technisch genug bewandert bist, kannst du alles lokal ablaufen lassen OHNE cloud ...
( sollte man "remote" darauf zugreifen wollen, kann man vpn nutzen ... oder einen cloud-service des smarthome-systems )
störungen des "internets" ( provider / cloud-anbieter / whatever ) haben keinen einfluss auf das produkt.
einen "point of failure" weniger.
und einige ( wie ich auch ) präferieren ein smarthome-system ganz ohne externe abhängigkeiten.
sowie auch die funktionalitäten für die zukunft zu garantieren.
das gute ist ja, du kannst das nutzen, musst es aber nicht ... dir wird die wahl gelassen.
Du hast mich falsch verstanden.
Ich frage mich, ob ich einen Vorteil durch das eigene MQTT habe?
Wenn ich den ESP habe, kann ich den Speicher ja vom Internet kappen - den HA kann ich dann über VPN erreichen... Habe ich einen Nachteil, gegenüber dem Amazon MQTT, wenn ich die ESP Lösung nutze?
g ... bin gerade aus dem bett gestolpert ... ☕
die vorteile des lokalen ( die mir eingefallen sind ) habe ich ja gerade beschrieben.
wenn man das fortführt ... ist eine kombination aus esp32 und amazon-mqtt ( oder lokal ) nicht verkehrt ( hängt von den eigenen präferenzen ab ).
bei lokalen mqtt treffen halt die vorteile zu, die ich vorab erwähnt habe. der nachteil ist, du musst dich damit beschäftigen ( was nicht unbedingt ein nachteil sein muss )
mit dem esp32 hast du sogar momentan mehr vorteile ( wenn richtig genutzt ),
als wenn man nur auf mqtt ( lokal oder amazon ) setzt:
du kannst dir die zellinfos anzeigen lassen und bei definierten zuständen entsprechend reagieren.
der einizige mögliche nachteil, den ich gerade bei der esp32 lösung sehe: die ständige zusätzliche ble verbnindung könnte das system instabiler machen, als eine reine mqtt-lösung ...
ich werde bspw. auch bei der esp32 lösung bleiben ( spiele aber auch mit dem mqtt, aus neugier halt ) .
@noone2k es war ziemlich komisch der Timer
2-3 waren aktiv wobei der Timer 2 100w 00:00-00:30 hatte und der Timer 3 auch einen Wert wo ich nicht mehr weiß. Das ist mir 2 x passiert bei dem Versuch über den Speicher zu regeln. Nach dem mir die EPRom Sache in den Kopf kam habe ich es lieber gelassen . Der Speicher soll seine 5000-6000 Zyklen halten.
diese "geregelte" steuerung über timer 3 sollte nur dafür genutzt werden,
mal schnell die steuerung für sich anzupassen und ist dafür "reserviert".
momentan ist die logic im script wie folgt:
timer 1+2 kann man gleichzeitig aktivieren. dabei wird timer 3 immer deaktiviert ( aber keine anderen werte verstellt ).
wenn man timer3 aktiviert, werden timer 1+2 deaktiviert ( und auch hier, ich deaktiviere nur die timer, aber setze keine anderen werte ).
da timer3 im script für die manuelle ansteuerung der ausgabe reserviert ist, sollen die anderen timer sich nicht in die quere kommen.
wenn sich doch andere werte verändern ( zeiten oder power ) , müsste ich mal gegenprüfen unter welchen umständen.
da fällt mir ein, das ich mal gucken könnte welcher timer priorität hat, wenn sich zeiten überlappen ;)
oder falls es jmd weiss, gerne antworten ...
für den v1 habe ich gerade die 1.39 entdeckt ...
sieht auf dem ersten blick nach einen bugfix release aus ... keine neuen funktionen ...
Ich habe eine Frage, nicht direkt zu diesem Projekt, welches einwandfrei funktioniert, sondern zu einem seltsamen Verhalten meiner Batterien, das mir erst duch die Homeassistant Integration aufgefallen ist. Vielleicht kennt jemand hier dieses Problem und kann dazu etwas sagen.
Ich Verwende 2 v1 Batterien, mit HM-800 Wechselrichtern und Nulleinspeisung mit DTU-Pro. Läuft eigentlich sehr stabil, jedoch ziehen die Wechselrichter nachts, immer wenn der Verbrauch nahezu 0 ist, in scheinbar regelmäßigen Abständen kurz die volle Leistung.
Die DTU dürfte dafür verantwortlich sein, da dies bei beiden Batterien gleichzeitig auftritt. Die in der Grafik erkennbaren Pausen, entstehen, wenn der Kühlschrankkomressor läuft.
Welche Firmwareversion hast Du ?
Ich habe einen ähnlichen Effekt, ebenfalls V1, das der Speicher hin und wieder kurz die Ausgänge trennt und somit die Wechselrichter ausschaltet. Ganz klar das dann beim Restart die WRs erst mal auf 100% gehen bis die DTU wieder zurück regelt.
Workaround, ein persistentes Limit dem WR geben, bspw. 10W. Dann wird beim Einschalten erst mal auf 10W geregelt und die DTU paßt das dann entsprechend an.
Dieses seltsame Verhalten vom Speicher trat bei mir erstmals mit der V136 auf 😳
@phoen Firmware v138 ? Die hat scheinbar ein Problem, wenn zu wenig an Strom an Out1 ausgegeben wird. Dann macht der Speicher nen Restart/Reset und der WR schaltet sich ab. Dann dauert es ca. 3-4 Minuten bis die Speicher wieder liefern und noch ca. 1 Minute bis der WR wieder geregelt wird. Wenn nur Out2 angeschlossen ist, dann macht er das nicht!
Hast du beide Speicher am HM-800 über Out1 verbunden? Dann teste mal, ob der Anschluss an Out2 Verbesserung bringt. Oder du bittest die Fa. Schuss darum, dir wieder die v135 zur Verfügung zu stellen.
Danke für den Tipp, ich hatte erst die DTU im Verdacht, weil die Spikes zeitgleich passieren. die BLE Disconnects zeigen aber ein recht eindeutige Bild. Ich habe jeweils beide Ausgänge an die HM-800 angeschlossen.
Die Speicher laufen mit v138. Davor dürfte das Problem nicht aufgetreten sein.
@knickohr Wie kann ich das persistent Limit setzen, ohne das Export Limit zu verändern?
Das sollte mit der DTU gehen. Original Hoymiles DTU ?
Es gibt 2 Limits, ein festes und dauerhaftes, das beim Einschalten des WRs gesetzt ist. Dieses verbleibt im EEPROM des WRs. Und ein temporäres das normalerweise für eine Nulleinspeisung genutzt wird und bei dem sich die Werte schnell ändern.
So ich habe hier nun schon einiges gelesen und verstehe auch den Sinn der ESP32 also mqtt Server bzw Bluetooth Bridge.
Nun habe ich NodeRed auf einem Raspberry und könnte ja direkt per Bluetooth die Daten abziehen aus dem BC2500 korrekt ?
Weiß jemand mit welchem Bluetooth Passwort man sich verbindet und wie sowas in etwa technisch abläuft ? Mit welchem Weg bekommt auch der ESP32 die Daten aus dem BC2500 ? MQTT Client ist er ja scheinbar ?!
Grüße und viel Sonne,
Daniel