Closed wildekek closed 11 months ago
I do have the RD6018 and would like to install this to it to have it under esphome/hass control and be able to log long term data, especially for my lifepo4 battery bank top balance formation runs. So I could test this if it's already merged.
Found the following differences between the models: Model number: 60062 Name: RD6006 Voltage precision: 2 Current precision: 3 Max voltage: 60 Max current: 6 60065 Name: RD6006P Voltage precision: 3 Current precision: 4 Max voltage: 60 Max current: 6 60121 Name: RD6012 Voltage precision: 2 Current precision: 2 Max voltage: 60 Max current: 20 60181 Name: RD6018 Voltage precision: 2 Current precision: 2 Max voltage: 60 Max current: 18
I'll try and make support for the other models in the near future. Could you help me test the RD6018 @chron0 ? I would like to know if the model number shows up correctly using the latest version of the main branch. I can then change some parameters and make it work, should be fairly simple.
I could give it a try, it's been a while since I pimped my riden (see https://odysee.com/@Apollo-NG:2/pimp-my-riden-1:1?r=9GPazzWhkRN7uXjT7tbgNuzpoZAF4G6Z&t=6064) but the next time i rotate back to it I could try this yaml config instead to test it for the rd6018 and will report back on it.
I have a 6012 if you need a tester.
I have RD6018 with UniSoft firmware 1.41.1k, and I can confirm, that everything works after these changes are applied:
@@ -1,6 +1,6 @@
substitutions:
- device_name: "rd6006-controller"
- device_friendly_name: "RD 6006"
+ device_name: "riden-rd6018"
+ device_friendly_name: "Riden RD6018"
device_description: "Power Supply"
time_timezone: "Europe/Amsterdam"
@@ -10,7 +10,7 @@
comment: $device_description
name_add_mac_suffix: false
project:
- name: "wildekek.rd6006-controller"
+ name: "wildekek.rd6018-controller"
version: "1.3.2"
esp8266:
@@ -160,7 +160,7 @@
value_type: U_WORD
accuracy_decimals: 3
filters:
- - multiply: 0.001
+ - multiply: 0.01
- platform: modbus_controller
modbus_controller_id: powersupply
@@ -409,9 +409,9 @@
entity_category: config
value_type: U_WORD
min_value: 0
- max_value: 6
+ max_value: 60
step: 0.01
- multiply: 1000
+ multiply: 100
- platform: modbus_controller
modbus_controller_id: powersupply
@@ -383,9 +383,9 @@
address: 9
value_type: U_WORD
min_value: 0
- max_value: 6
- step: 0.001
- multiply: 1000
+ max_value: 60
+ step: 0.01
+ multiply: 100
# Date components are kept internal
- platform: modbus_controller
I have tested all sensors except temperature external, because I never used it. Disconnected probe shows 65,625stC. Current is shown in 10mA steps, on UniSoft's fw this value is interpolated and accuracy is 1mA on display. This is not really a problem for me, but worth noting.
If accuracy of current is reported up to two decimals, then I think that we can add this too:
esp8266:
@@ -158,9 +158,9 @@
unit_of_measurement: "A"
register_type: holding
value_type: U_WORD
- accuracy_decimals: 3
+ accuracy_decimals: 2
I think that second file in this repository for RD6018 should be best solution.
Thanks for Your work!
I'm not super familiar with esphome, but couldn't the lambda if x true false be simplified to just return the condition directly?
EDIT: Yes, you can lambda: return X;
instead
Though a file for each model wouldn't be a bad idea, the only difference is voltage/current min/max/multipliers, which can either be set using a variable by user or determined by the model number automatically. See here
Thanks for all your efforts to get other models tested and included! Since the diff between the models is so small, the neatest solution imo is to make 1 file that supports all models. That way it is easier to update in the future. I think I can write something that checks the model once during startup and saves the accuracy/range values to EEPROM. I'll work on it a bit this week and will poke this thread when I have a testable version.
I'm not super familiar with esphome, but couldn't the lambda if x true false be simplified to just return the condition directly?
EDIT: Yes, you can
lambda: return X;
instead
I don't understand which code you're referring to and how this is related to this issue, help me.
https://github.com/wildekek/riden-esphome/blob/main/rd6006-controller.yaml#L321-L326
This format can be replaced with just lambda: return id(protection_status).state == 1;
So, I just checked out the possibility of setting the differences between models (like accuracy and min/max current) based on the model name (available since v1.3.3 59bf17debba40bc707cccee08bd506463f199ce6). The issue however is that ESPHome does not allow templates in configuration variables (like max_value in a modbus number).
The most elegant solution I can think of, is to have a main yaml which substitutes a model specific yaml like so:
#in rd-powersupply.yaml
<<: !include 6018.yaml
Any more elegant ideas?
Are you able to use lambdas in configuration variables? global variables with lambdas, the yaml substitutes are a good solution if not
I'm not sure if you'd have to use lambda:
or !lambda
format
No, lambda's in configuration variables are not an option. I'm working on a pretty clean solution using substitutions like so:
substitutions:
# Change this model to fit your particular one.
# You can find it in Home Assistant as the device diagnostic "Model Name".
model: "RD6006"
device_name: "rd6006-controller"
device_friendly_name: "RD 6006"
device_description: "Power Supply"
time_timezone: "Europe/Amsterdam"
# Model specific settings (Don't change these!)
RD6006_max_voltage: "60"
RD6006_max_current: "6"
RD6006_voltage_precision: "2"
RD6006_current_precision: "3"
RD6006P_max_voltage: "60"
RD6006P_max_current: "6"
RD6006P_voltage_precision: "3"
RD6006P_current_precision: "4"
RD6012_max_voltage: "60"
RD6012_max_current: "12"
RD6012_voltage_precision: "2"
RD6012_current_precision: "2"
RD6018_max_voltage: "60"
RD6018_max_current: "18"
RD6018_voltage_precision: "2"
RD6018_current_precision: "2"
snip
max_value: ${${model}_max_voltage}
I created 1.4.0 as a beta release, go check it out! If it is confirmed to work, let me know. Your help is appreciated! https://github.com/wildekek/rdtech-esphome/releases/tag/1.4.0
Nice!
❓ RD6006P: Needs testing: check out the latest release candidate (> 1.4)
❓ RD60012: Needs testing: check out the latest release candidate (> 1.4)
❓ RD60018: Needs testing: check out the latest release candidate (> 1.4)
🛑 RD60024: Not supported. You're welcome to make a pull request :)
It's RD6012, RD6018, RD6024, one zero too much ;)
I will test RD6018 and post results.
You added an extra 0 to the 12 and 18 substitution model number variable names, I wish these things could do 600v output lol
EDIT: Dom4n beat me to it EDIT2: The link to the yaml file in the flashing section of the readme is broken EDIT3: If you use the custom firmware you can use higher baudrates and increase the polling speed (if you want), I can use max 1,000,000 but sometimes, using some modbus libraries I can only get 500,000
It seems to work for me on my RD6018
Would it be possible to add a button that syncs the units date/time with home assistant, because even with the internal battery it never saves the time for me
Nice!
❓ RD6006P: Needs testing: check out the latest release candidate (> 1.4) ❓ RD60012: Needs testing: check out the latest release candidate (> 1.4) ❓ RD60018: Needs testing: check out the latest release candidate (> 1.4) 🛑 RD60024: Not supported. You're welcome to make a pull request :)
It's RD6012, RD6018, RD6024, one zero too much ;)
I will test RD6018 and post results.
Fixed! Thank you for testing, appreciated!
It seems to work for me on my RD6018
Would it be possible to add a button that syncs the units date/time with home assistant, because even with the internal battery it never saves the time for me
This is my modified version
Please create a new issue, let's discuss there.
Edit: See #2
EDIT2: The link to the yaml file in the flashing section of the readme is broken.
Fixed!
If anyone is able to test the RD6006P or RD6012, I'd be super happy! 🙏
I'm going to close this issue and release it. There was enough chance to test it and any issues should be low-risk and can go into new issues. Thanks!
I'd love to support the other Riden power supply types and it seems that the protocol is fairly similar:
Unfortunately I do not have these units to test, and I feel uncomfortable releasing software for controlling a PSU that people use for charging LiPo batteries and other spicy components that I can't test IRL.