I would like to participate in this engineering prototype to control my electric hotwater heater, the element in this hotwater cylinder is 1KW as you can see from my IAM Meter screenshot below, running this day between approx 8:15am and 2:15pm.
This is currently triggered by an automation in homeassistant IAMMeter Modbus when consumption and generation has at least 1KW of free capacity that would normally be exported, reacting every 1 second. Example of this below. I installed a 1KW element in it so on cloudy days I could mostly heat hot water still, if I get this device I am willing to up this to 2.5KW element to make the most of self consumption over most of the day.
I already have monthly reporting in place which is emailed to myself, here is an example of my billing
Today the device functioned well, it turned on when expected, from below arrow 1, I can't explain the little spike in the set_power. Drop 2 is my salt water chlorinator turning on and the device adjusting accordingly.
The device today had a tendency to favour importing from the grid slightly with the default Hysteresis and Threshold after the last update, I have now tweaked these to favour slight export 85W. Item 3 below is when I made the adjustments
Graphs so far today
Awesome,
Thanks so much for the awesome improvements!!!
Please upgrade to the latest version again.
https://github.com/lewei50/Solar-PV-Monitoring/blob/master/ESPHome/scr-485.yaml
Yes, we add such feature in the latest YAML recently
Restore power: the maximum power when it leaves the auto period.
Ex; if you set the Restore power = 1000 , it means the max power of the heater is limited to 1kw when it is not in the auto period.
You can also set it to 0 w. which means the heater will not work when it is not in the auto period.
We also add these two fields
Version: the YAML version number
X current time: show the current time , we doubt the time is not correct when the TZ is not set in the previous version(it will affect the judgment for the auto period ), so we added this field.
Can we have a toggle for the logic to allow the device to heat the hot water outside of the "start time" and "end time" so people who do not want to heat the hot water over night and wait until the next day of generation to heat the water.
If we can't do what I am asking what is the impact if any. If I switch the device on at 8am and off at 3pm with an automation on the power circuit?
#################################################
##scr-485.yaml##
#################################################
## Add in your secrets.yaml
# wifi_ssid: 'iammeter'
# wifi_password: '12345678'
#################################################
esphome:
name: scr-485
friendly_name: scr_485
platformio_options:
# platform: https://github.com/platformio/platform-espressif32.git#feature/arduino-upstream
board_build.flash_mode: dio
## If you want to use auto mode please enable auto_mode_switch below, if you have battery you can enable with_battery
# on_boot:
# then:
# - switch.turn_on: auto_mode_switch
# - switch.turn_on: with_battery
esp32:
board: esp32-c3-devkitm-1
framework:
type: arduino
## Enable logging
# logger:
# level: DEBUG
## Enable Home Assistant API
api:
# encryption:
# key: "sgCuRJxLsye8p+zn6/0+TaijdeinqqayDoHTboX6TlQ="
reboot_timeout: 0s
ota:
# password: "279ec37f5bec6c4097b63bf9af78d375"
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
## Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Scr-485"
# password: "12345678"
web_server:
port: 80
local: true
version: 2
time:
- platform: sntp
id: sntp_time
# servers: ntp5.aliyun.com #NTP server address
# timezone: Asia/Shanghai
captive_portal:
globals:
- id: auto_mode
type: bool
restore_value: true
initial_value: 'false'
- id: global_with_battery
type: bool
restore_value: true
initial_value: 'false'
- id: interval_flag
type: bool
restore_value: true
initial_value: 'false'
- id: non_pvp_flag
type: bool
restore_value: true
initial_value: 'false'
http_request:
useragent: esphome/device
timeout: 10s
id: http_request_data
status_led:
pin:
number: GPIO08
inverted: true
# light:
# - platform: status_led
# name: "Status Led"
# pin:
# number: GPIO08
# inverted: true
uart:
id: mod_bus
tx_pin: 0
rx_pin: 1
baud_rate: 9600
stop_bits: 1
modbus:
# flow_control_pin: 8
id: modbus1
modbus_controller:
- id: modbus_device
address: 0x01 ## address of the Modbus slave device on the bus
modbus_id: modbus1
setup_priority: -10
update_interval: 3s
sensor:
- platform: modbus_controller
modbus_controller_id: modbus_device
name: "scr_485_adc_read"
id: im1266_voltage
register_type: holding
address: 0x0001
# unit_of_measurement: "ADC"
value_type: U_WORD
# accuracy_decimals: 4
# filters:
# - multiply: 0.0001
- platform: template
name: "Grid Power"
id: grid_power
unit_of_measurement: "W"
update_interval: 3s
# - platform: template
# name: "Grid Power REV"
# id: grid_power_rev
# unit_of_measurement: "W"
# update_interval: 3s
- platform: template
name: "Battery Power"
id: battery_power
unit_of_measurement: "W"
update_interval: 3s
# - platform: template
# name: "Battery Power REV"
# id: battery_power_rev
# unit_of_measurement: "W"
# update_interval: 3s
number:
- platform: modbus_controller
modbus_controller_id: modbus_device
id: scr_485_set_adc
name: "scr_485_set_adc"
address: 0x0002
value_type: U_WORD
# multiply: 1.0
min_value: 0
max_value: 4096
- platform: template
id: max_power
name: "Max Power"
optimistic: true
min_value: 1
max_value: 3600
step: 1
initial_value: 3600
restore_value: True
unit_of_measurement: "W"
- platform: template
id: threshold
name: "Threshold"
optimistic: true
min_value: -200
max_value: 200
step: 0
initial_value: -20
restore_value: True
unit_of_measurement: "W"
- platform: template
id: hysteresis
name: "Hysteresis"
optimistic: true
min_value: 0
max_value: 200
step: 0
initial_value: 50
restore_value: True
unit_of_measurement: "W"
- platform: template
id: set_power
name: "Set Power"
unit_of_measurement: "W"
optimistic: true
min_value: 0
max_value: 3600
step: 1
# initial_value: 1500
restore_value: True
on_value:
then:
- number.set:
id: scr_485_set_adc
value: !lambda |-
uint16_t input_val = id(set_power).state;
uint16_t output_val = 0;
uint16_t max_power_val = id(max_power).state;
if (input_val <= 0){
output_val = 0;
}else if (input_val <= max_power_val) {
output_val = 1450 + (input_val - 0) * (4096 - 1450) / (max_power_val - 0);
}else{
output_val = 4096;
}
return output_val;
- platform: template
id: auto_start_time
name: "1 Start Time"
optimistic: true
min_value: 0
max_value: 24
step: 1
initial_value: 9
restore_value: True
- platform: template
id: auto_end_time
name: "2 End Time"
optimistic: true
min_value: 0
max_value: 24
step: 1
initial_value: 16
restore_value: True
- platform: template
id: interval_seconds
name: "4 Interval Seconds"
unit_of_measurement: "s"
optimistic: true
min_value: 1
max_value: 30
step: 1
initial_value: 3
restore_value: True
interval:
- interval: 1s
then:
lambda: |-
static int counter = 0;
counter++;
if (counter >= id(interval_seconds).state) {
counter = 0;
id(interval_flag) = true;
ESP_LOGI("main", "Interval triggered");
}
- interval: 1s
then:
## During non-PV power generation period, reset the set power to the maximum power
- if:
condition:
# lambda: 'return id(auto_mode);'
and:
- lambda: 'return id(interval_flag);'
- lambda: 'return id(auto_mode);'
- lambda: 'return !id(non_pvp_flag);'
- lambda: 'auto time = id(sntp_time).now(); return (time.hour == id(auto_end_time).state) && (time.minute == 0);'
then:
- lambda: |-
id(non_pvp_flag) = true;
id(set_power).publish_state(id(max_power).state);
ESP_LOGI("main", "non_pvp_flag");
- if:
condition:
# lambda: 'return id(auto_mode);'
and:
- lambda: 'return id(interval_flag);'
- lambda: 'return id(auto_mode);'
- lambda: 'return id(non_pvp_flag);'
- lambda: 'auto time = id(sntp_time).now(); return time.hour >= id(auto_start_time).state && time.hour < id(auto_end_time).state;'
then:
- lambda: |-
id(non_pvp_flag) = false;
ESP_LOGI("main", "pvp_flag");
## Main regulation logic
- if:
condition:
# lambda: 'return id(auto_mode);'
and:
- lambda: 'return id(interval_flag);'
- lambda: 'return id(auto_mode);'
- lambda: 'auto time = id(sntp_time).now(); return time.hour >= id(auto_start_time).state && time.hour < id(auto_end_time).state;'
then:
- lambda: |-
id(interval_flag) = false;
ESP_LOGI("main", "interval_flag");
## with Battery
- if:
condition:
lambda: 'return id(global_with_battery);'
then:
- http_request.get: ## IP of the meter that measures the battery power.
url: "http://192.168.10.5/monitorjson"
headers:
Content-Type: "application/json"
Authorization: 'Basic YWRtaW46YWRtaW4='
verify_ssl: false
on_response:
then:
- logger.log:
format: "Response status: %d, Duration: %u ms"
args:
- status_code
- duration_ms
- lambda: |-
json::parse_json(id(http_request_data).get_string(), [](JsonObject root) {
// WEM3080
if (root.containsKey("Data") && root["Data"].is<JsonArray>() && root["Data"].size() > 2) {
int32_t tmp_battery_power = root["Data"][2];
//tmp_battery_power = -tmp_battery_power; //for test
id(battery_power).publish_state(tmp_battery_power);
// int32_t tmp_battery_power_rev = -tmp_battery_power;
// id(battery_power_rev).publish_state(tmp_battery_power_rev);
}
});
- http_request.get: ## IP of the meter that measures the grid power.
url: "http://192.168.10.5/monitorjson"
headers:
Content-Type: "application/json"
Authorization: 'Basic YWRtaW46YWRtaW4='
verify_ssl: false
on_response:
then:
- logger.log:
format: "Response status: %d, Duration: %u ms"
args:
- status_code
- duration_ms
- lambda: |-
json::parse_json(id(http_request_data).get_string(), [](JsonObject root) {
// WEM3080
if (root.containsKey("Data") && root["Data"].is<JsonArray>() && root["Data"].size() > 2) {
int32_t tmp_grid_power = root["Data"][2];
id(grid_power).publish_state(tmp_grid_power);
// int32_t tmp_grid_power_rev = -tmp_grid_power;
// id(grid_power_rev).publish_state(tmp_grid_power_rev);
int32_t tmp_threshold = id(threshold).state;
int32_t tmp_hysteresis = id(hysteresis).state;
int32_t tmp_set_power = id(set_power).state;
if ((id(global_with_battery))&&id(battery_power).state<0) {
tmp_grid_power = tmp_grid_power - id(battery_power).state;
}
if (tmp_grid_power < tmp_threshold - tmp_hysteresis) {
tmp_set_power += abs(tmp_grid_power - tmp_threshold);
if (tmp_set_power < 0) {
tmp_set_power = 0;
}
if (tmp_set_power > id(max_power).state) {
tmp_set_power = id(max_power).state;
}
if (id(auto_mode)) {
id(set_power).publish_state(tmp_set_power);
}
}
if (tmp_grid_power > tmp_threshold + tmp_hysteresis) {
tmp_set_power -= abs(tmp_grid_power - tmp_threshold);
if (tmp_set_power < 0) {
tmp_set_power = 0;
}
if (tmp_set_power > id(max_power).state) {
tmp_set_power = id(max_power).state;
}
if (id(auto_mode)) {
id(set_power).publish_state(tmp_set_power);
}
}
}
// WEM3080T/WEM3050T/WEM3046T
if (root.containsKey("Datas") && root["Datas"].is<JsonArray>() && root["Datas"].size() > 2) {
// If your solar PV uses phase A, it is ["Datas"][0][2], if it is phase B, it is ["Datas"][1][2], if it is phase C, it is ["Datas"] [2][2]
int32_t tmp_grid_power = root["Datas"][2][2];
//tmp_grid_power = -tmp_grid_power; //for test
id(grid_power).publish_state(tmp_grid_power);
// int32_t tmp_grid_power_rev = -tmp_grid_power;
// id(grid_power_rev).publish_state(tmp_grid_power_rev);
int32_t tmp_threshold = id(threshold).state;
int32_t tmp_hysteresis = id(hysteresis).state;
int32_t tmp_set_power = id(set_power).state;
if ((id(global_with_battery))&&id(battery_power).state<0) {
tmp_grid_power = tmp_grid_power - id(battery_power).state;
}
if (tmp_grid_power < tmp_threshold - tmp_hysteresis) {
tmp_set_power += abs(tmp_grid_power - tmp_threshold);
if (tmp_set_power < 0) {
tmp_set_power = 0;
}
if (tmp_set_power > id(max_power).state) {
tmp_set_power = id(max_power).state;
}
if (id(auto_mode)) {
id(set_power).publish_state(tmp_set_power);
}
}
if (tmp_grid_power > tmp_threshold + tmp_hysteresis) {
tmp_set_power -= abs(tmp_grid_power - tmp_threshold);
if (tmp_set_power < 0) {
tmp_set_power = 0;
}
if (tmp_set_power > id(max_power).state) {
tmp_set_power = id(max_power).state;
}
if (id(auto_mode)) {
id(set_power).publish_state(tmp_set_power);
}
}
}
});
switch:
- platform: template
name: "3 Auto Mode Switch"
id: auto_mode_switch
restore_mode: DISABLED
turn_on_action:
- globals.set:
id: auto_mode
value: 'true'
turn_off_action:
- globals.set:
id: auto_mode
value: 'false'
# - number.set:
# id: set_power
# value: '0.0'
lambda: |-
return id(auto_mode);
- platform: template
name: "3 With Battery"
id: with_battery
restore_mode: DISABLED
turn_on_action:
- globals.set:
id: global_with_battery
value: 'true'
turn_off_action:
- globals.set:
id: global_with_battery
value: 'false'
lambda: |-
return id(global_with_battery);
button:
- platform: restart
name: "Restart"
No set power between start and finish, it is currently 12pm here
The only way I can get this device to operate is to set the start time to 12am Midnight and it is 12pm here
Interesting because prior to this latest yaml everything seemed to function and make sense, now it does not.
prior
start_time is set at 8am, device ran and heated water when there was generation after 8am.
end_time is set at 4pm, device did not attempt to heat hot water over night, except once due to bug.
now
start_time the device has done nothing because I believe you have the start_time and end_time accidently switched, see post picture above.
end_time did not end anything appeared to turn the hot water on over night, if I wanted to heat my hot water over night why would we want this device? I could just leave the power on to the hot water 24/7.
Isn't the point of this project self-use, not consumption. If your plan is to turn the hot water cylinder on and leave it on over night, then this project is not for me. Because I will pay for hot water heating then EVERY night.
I think it would be better if someone needs to boost the hot water that this is a manual choice/decision.
It would also be useful to provide a method for limiting the maximum power of the heater when it's outside the auto period. We can discuss this further later.
This is not a bug.
Here’s how it works:
When you enable the "auto switch mode," the SCR-485 is designed to automatically set the power output to its maximum once it exits the auto period. This means that every day at 16:01, the power will revert to 2410W, effectively returning control to the thermostat. This setup ensures that the heater remains operational when there is not enough hot water, even if it's outside the auto period.
In simpler terms, this logic can be summarized as below,when "auto switch mode" is enabled and it's not during the designated auto period, the SCR-485 is bypassed.
As a result of my report above, my hot water ran this morning, with no generation has to be a bug.
Ok,
I have worked it out now, the start time and the end time are now flipped for me
Where the Start Time appears to be setting what should be the end time, and the end time I assume is now the start time.
I had to set the Start Time to before 6am to get grid data, and it is 6 pm here.
I have just updated the device and note the grid rev is now not shown, I adjusted the slider "end time" to check if the grid detail was updating, and it didn't. Then I tried a restart from this screen.
After the restart the grid no shows as NA
From HA to Sensor for Grid is unknown as below
I have attempted a power off and back on the the grid information remains missing, going to attempt the update again.
It would be best if you can manually add valid ntp and zone. Of course, if you block them, esphome will automatically set them according to the host machine.
Hi thanks for this, the "start time" and "end time" appeared to be working as I was expecting, for example if I adjusted the end time during the day to say 3pm when it was just after 3pm the grid data would stop updating.
In addition there is not enough time difference to Brisbane/Australia where this time zone would switch off or on opposite to expectation, eg 12 hours difference, which would be time zone in the Americas?
Can I update this to?
servers: au.pool.ntp.org
timezone: Brisbane/Australia
I can imagine that the real time clock in these devices is not great, and no NTP would cause time shifts?
Thanks for your feedback,
Please upgrade to the latest YAML again.
This is the introduction
Latest version of the YAML for SCR-485
1. I was watching the device through the web page prior to 8am, and auto mode was set, no grid data but this is expected with the start time and end times set.
1a. My device was set with the start time as 8am, as soon as 8am came the device either rebooted for what ever reason, or caused an exception that caused the auto mode switch to toggle to the off state. The power state of the device remained on.
1b. I went back to the web portal of the scr-485 and toggled the auto mode switch, and it put set_power at max 2.4KW, and the Grid power readings were N/A as per the diagrams in post above 2024-06-11 06:24. See graph below, red arrow is me toggling the auto mode switch. Green arrow is me hard powering off the scr-485 with a switch, powering it back on allows the device to operate as normal after about 8:30am.
Here is the state of power to the scr-485
1. From above is me Turning the device back on after turning it off straight after conducting the new yaml build update to the device, as it appeared that the device was not working as expected because the set_power went straight to 2.4KW. This recovered after turning off and on.
2. Me turning off the device at 8:26am attempting to fix the issue reported top of post, no set_power auto adjustment due to no grid data.
3. Me turning the scr-485 back on, the toggling the auto mode switch to on, and the scr-485 working then as expected
So you can see from this the state of power to the device, was on the entire time between the times explained above.
Hope this helps
'Over night the device remained on, the auto switch was on. 8am came when it was supposed to switch on, auto ended up switched off and when switching it back on, the device appears to have hung.'
Regarding this issue, it should be because you set the timezone to Asia/Shanghai. Just block servers and timezone.
like this
summarize your issue, please let me know whether the summary below are correct.
1 the "auto mode" does not turn on automatically when it is after 8 am (start time)
2 when you turn on the "auto mode switch" manually, the grid power is always not displayed and the set_power keeps on the maximum power in around 20 mins.
Please also let me know,whether the scr-485 is accessible before you power reset it(I guess you have visited the web page and it open successfully ,but I need to confirm again)
I found that the time you posted showed 6:24. Does it correspond to the time on your side which is 8:24? Then I need to confirm that the device scr-485 did not get grid power for 20 minutes from 8:00 to 8:24.
Over night the device remained on, the auto switch was on. 8am came when it was supposed to switch on, auto ended up switched off and when switching it back on, the device appears to have hung.
After turning the device auto mode back on, it just set the set_power to max with no reading data from the Grid, as below
Showing that it did in fact set the power to max
Hi
As I have introduced in previous replies, the set_power would be resumed to the maximum power when it quit the "automatic switch mode" in the latest YAML.
And the reason is explained as below.
You can understand it this way: when 'automatic switch mode' is enabled, the set_power is controlled in real-time based on the solar surplus during the period between the start time and end time. When outside this time frame, the set_power reverts to max power, as if the SCR-485 device does not exist.
I have updated to the latest YAML
1. The behaviour for this was different it seemed to remember the last WIFI connection settings.
2. It appeared that it didn't restart after the firmware update, and I was able to reproduce the stuck set_power issue.
3. I fully powered down the device and started it again, and now I couldn't reproduce the set_power issue, so assume it has updated.
Can I suggest that we write a version number to the scr-485 page, so we know what build we are running?
I will update the yaml because I believe this was the issue I was seeing.
And in answer to your question above, yes the consumption on the 8th also was greater or equal to the generation
I have just looked at this device now and the power was set to 2.4KW still at 6pm and it was very dark here as below
I had the device to switch to off at 4pm, I think this caused it to stay online until now, I just manually set the off time to 6pm and toggled the 3 Auto Mode Switch, you can just see at the end of the graph that the set power has now gone to zero. I set it like this to be the same as recommended in you setup post as below.
Thank you for providing the detailed information. Yes, that is exactly the purpose of our experiment. We organized this activity to use the power curve information provided by customers to help us analyze whether the operations performed by the SCR-485 are reasonable, so as to further upgrade the functionality of the SCR-485.
As you described below.
8 June switched to 0 at 3:46 pm
Could you please also provide the grid power status at these corresponding time （3:46pm at June 8th,）？
If the grid power is also close to zero at that time, then it can be reasonably explained as below.
If the grid power is also close to zero, it indicates that other loads are using the solar surplus at that time, leaving insufficient surplus to supply the heater. Consequently, the set power will be zero. Furthermore, the auto switch mode is disabled after 4pm, which means the set power remains at zero after 4pm until the next automatic cycle starts (after 7am the following day).
By the way, this is the latest version of the YAML now. Please upgrade it.
https://github.com/lewei50/Solar-PV-Monitoring/blob/master/ESPHome/scr-485.yaml
There was a bug in the previous YAML configuration. When outside the automatic cycle, the set_power remained at the last set value, which could cause issues. For example, if set_power was set to zero, the boiler's heater would not function until the next automatic cycle began.
A significant upgrade has been implemented in the latest YAML version. Now, after exiting the auto switch mode, the set_power will revert to maximum power instead of maintaining the last set value from the automatic switch cycle (such as the zero power value on June 8th). These upgrades ensure that the heater returns to thermostat control after leaving the automatic cycle.
Apart from what I have just written above, I have no idea why it would do this. All I am reporting is a difference to the day before, and differences to all days prior to installing the latest yaml yesterday.
I can explain why there is no data after 2:30pm yesterday this is because the switch was manually turned off by accident which was switched back on about 7:30am today.
Here are the previous days, this was the day the device was installed 7 June switched to zero until the next day from 3:44pm
8 June switched to 0 at 3:46pm, this time I can see actually co-insides at exactly the time where the generation is equal or less than the consumption.
So if this is the expected behaviour then that is fine, that was what I was trying to understand. I reported it because it was different than what I had previously noted, isn't this is what this testing is for?
I also don't want to do damage to the device if it is doing something that it is not supposed to be.
Hi:
Why is the set power consistently zero during this period, as indicated in the red rectangle? Even if the thermostat cuts power to the boiler's heater, the set power would still fluctuate corresponding to variations in the grid power.
I have also noted today it appears that this device has not detected the thermostat switching off the power. I am not sure if it is supposed to do this or not? It has just set the output to the max power, as below, from the chart you can see that the hot water switched off at about 12:30pm
yesterday it stopped setting the power at 11:17 am
Which matches when the thermostat cut in yesterday, as below
Today it is still trying to set the power as below
12:10pm is where the hot water switched off via the thermostat.
Here is broken down to 1second refresh, and as you can see a number of grid imports, and exports.
We have a cloudy day today and this SCR-485 is going crazy not controlling the hot water heating at all, also causing substantial imports from the grid as below. I have tried to adjust the the interval setting even down to 1 second, which didn't seem to help. It seems to have settled down a bit and got back into sync again, I can only guess that the sun is more consistent.
Settings of the device
Ok, so everything is working fine and as expected now.
What do you need from us now? When and how often would you like the reports?
Additionally, the 'auto mode switch' value is currently set to 'false' in the latest YAML configuration.
This can pose an issue if the SCR-485 resets unexpectedly, as it would disable the 'auto mode' after the reset.
Therefore, we recommend setting the default value of the 'auto mode switch' to 'true', as discussed in this topic.
It is also important to configure the correct 'start time' and 'stop time' for the automation cycle.
2. I really don't understand your comments quite often and who or what they are directed at. Of course the meter was set correctly otherwise it wouldn't be working right? you saw this post 2024-06-08 07:21? It becomes confusing because it seems like you are telling me I have it setup wrong.
"Due to limitations highlighted in this discussion, ESPHome cannot save boolean parameters. Consequently, the 'with battery' and 'auto mode switch' options reset to their default values after the SCR-485 is reset. Previously, the YAML configuration set 'with battery' to true by default. This meant that even if you manually disabled this option, it would revert to 'true' upon any reset of the SCR-485.
I want to clarify that even if 'with battery' is automatically set to true after a reset, it will not be effective unless the corresponding IP is correctly configured.
It’s important to note that the default value for 'with battery' has been changed to false in the latest YAML version."
In response to your points
1. Thank you I will update the yaml
2. I really don't understand your comments quite often and who or what they are directed at. Of course the meter was set correctly otherwise it wouldn't be working right? you saw this post 2024-06-08 07:21? It becomes confusing because it seems like you are telling me I have it setup wrong.
The device today did not experience the same issues as yesterday, it continued to work and run as expected as soon as the generation surpassed the consumption, I did knock back the threshold to -30 because early in the morning at -20 was still using a little power from the grid.
Please update to the latest version of the YAML firstly.
Even if the 'with battery' option is enabled, it will not be effective unless you correctly configure the IP address of the meter monitoring the battery power in the YAML.
Have you updated the yaml to the latest?
If not ,please upgrade it now.
Then the default status of the "with battery " would be "off"
The device switched to battery again, i was wondering why it didn't start heating again after having showers.
I had to turn this battery mode off and switch on 3 Auto Mode Switch for it to start again.
Can you please provide the steps to remove this battery mode, and especially to be the default for people without batteries?
Here you can see it in live action, once the scr-485 was fully powered down and started again
Restarting the device multiple attempts it did not recover, I had to switch off the breaker switch for about 5 seconds then power it back on before it recovered.
I did switch it to auto once it worked, only did once I recompiled changing the CT clamp being.
I have discovered an issue, at some point over night, the device has switched to 3 With Battery by itself, therefore it was not working today. I have manually switched it this morning to 3 Auto Mode Switch, however the device appears to have locked up, no grid data.
I have completed a restart and the device auto switches to Battery mode, switching to 3 Auto Mode Switch, and the grid data is still not coming back, not sure what could be wrong.
Please try the auto mode , which would be a more fantastic effect.
So I now have the device installed and working.
Had an issue initially as it was reading the wrong CT, so I fixed it and reinstalled the SCR-485, the parts above the generation was me manually setting it. It took a little time to settle down then was very good at following the gen power curve, as shown below.
Will be great to see tomorrow how this looks
This is the control logic for the latest YAML .
If you do not have battery , please keep the option of "with battery" off(default value).
