For Ton:
Checked in 1V steps, also the preset format works fine:
Code: Select all
gp8403,preset,2,10V
Code: Select all
gp8403,volt,2,10
Moderators: grovkillen, Stuntteam, TD-er
Code: Select all
gp8403,preset,2,10V
Code: Select all
gp8403,volt,2,10
Just ask them if you're allowed some more time playing...localhorst wrote: ↑25 Jan 2024, 20:28 [...]
More testing to be done, as well as adding more DACs - but for now the kids need to go to bed.
Code: Select all
on MQTT_Import#Schaltstufe_WZSZ do
gp8403,volt,0,%eventvalue1%
endon
on MQTT_Import#Schaltstufe_Kinder do
gp8403,volt,1,%eventvalue1%
endon
Code: Select all
on MQTT_Import#Schaltstufe_WZSZ do
WZ_SZ.gp8403,volt,0,%eventvalue1%
endon
on MQTT_Import#Schaltstufe_Kinder do
WZ_SZ.gp8403,volt,1,%eventvalue1%
endon
Ah, nice as well, thank you!
Code: Select all
WZ_SZ.cmd_arg3/gp8403/volt/0
Code: Select all
cmd_arg3/WZ_SZ.gp8403/volt/0
It seems it doesn't work in ioBroker (or I'm too dump to do it correct again). Response is always "command unknown".
One more question, regarding moving away from GPIO-4:TD-er wrote: ↑25 Jan 2024, 18:04 I think you should try another GPIO pin for the I2C as GPIO-4 has an internal pull-down.
See: https://espeasy.readthedocs.io/en/lates ... e-on-esp32
Everyday learning with ESPeasy - lesson X.TD-er wrote: ↑26 Jan 2024, 12:14 On ESP32 (classic) you really should never(!!) use GPIO 12 for something that can pull-up or -down this pin during boot as it selects the voltage for the flash chip during boot.
Other pins with an exclamation mark do have some special properties or needs, so in general it means "look at the docs before connecting anything to it".
Set GPIO32 and GPIO33 - gorgeous - works like a charm.
It arrived today while I was at work, so I'll be playing with it tonight
Very nice, just like me.
For the moment, it seems all just fine - it was already pretty straight forward from the beginning.
That's a good idea! Saves people like me to see it not working in the first shot.
Code: Select all
- const uint8_t i2cAddressValues[] = { 0x58, 0x59, 0x5A, 0x5B, 0x5C, 0x5D, 0x5E, 0x5F };
+ const uint8_t i2cAddressValues[] = { 0x5F, 0x58, 0x59, 0x5A, 0x5B, 0x5C, 0x5D, 0x5E };
Hmm someone is getting familiar with the code toolocalhorst wrote: ↑27 Jan 2024, 10:22 [...]
*edit*
One comment, just cosmetics, but:I'd leave the sorting as it was for a better overview. The goal is already reached by PLUGIN_SET_DEFAULTS set to 0x5F,Code: Select all
- const uint8_t i2cAddressValues[] = { 0x58, 0x59, 0x5A, 0x5B, 0x5C, 0x5D, 0x5E, 0x5F }; + const uint8_t i2cAddressValues[] = { 0x5F, 0x58, 0x59, 0x5A, 0x5B, 0x5C, 0x5D, 0x5E };
The disadvantage is that the first item in the list is marked as (default), while in this case it isn't. Maybe the default value (or index) should be an extra argument to the function, with the first item as the default (pun intended ).TD-er wrote: ↑27 Jan 2024, 11:58Hmm someone is getting familiar with the code toolocalhorst wrote: ↑27 Jan 2024, 10:22 [...]
*edit*
One comment, just cosmetics, but:I'd leave the sorting as it was for a better overview. The goal is already reached by PLUGIN_SET_DEFAULTS set to 0x5F,Code: Select all
- const uint8_t i2cAddressValues[] = { 0x58, 0x59, 0x5A, 0x5B, 0x5C, 0x5D, 0x5E, 0x5F }; + const uint8_t i2cAddressValues[] = { 0x5F, 0x58, 0x59, 0x5A, 0x5B, 0x5C, 0x5D, 0x5E };
I totally agree with the suggested change.
Well, there is the 'Actions' tab in GH that shows the runs in date/time-descending order. You can probably recognize the PR title there. The current latest Actions Run, and with the latest GH-plugin updates, now implemented in our scripts, you can download a single build result as soon as it's finished (~1..3MB) (the list is 'somewhat longer' than before ), and finally a combined download will be added by the scripts (~273 MB).localhorst wrote: ↑27 Jan 2024, 10:22 Which GH Actions run will contain your changes? I'd like to test "Send out data for events/controllers when changing output values"
Great
There is still the documentation to do, that's also part of the repository, so only after completing that it should/will be merged.localhorst wrote: ↑27 Jan 2024, 17:56 When do you think this plugin will make it into a release? From my feeling, there is not so much left to do.
You can always update to a Release build once that's available, configuration will stay intact during update, unless you accidentally switch from SPIFFS to LittleFS (migration plan will be announced in the near future, as we'll migrate to LittleFS for all ESP32 builds), or use a different Flash/file-system layout.localhorst wrote: ↑27 Jan 2024, 17:56 So now I have to keep up with my hardware! Hopefully next week, I'll get to the point, that I'll install it into my system.
Just tested that myself. Besides the range-check in the plugin, the library does some recalculation of the voltage to the 12 bit range supported, but when set to 0-5V, and requesting 5V, that's what I actually measured on the output, so for me it works as intended
Fun fact: the load is now, since the DAC is connected, always between 10 and 20%.localhorst wrote: ↑24 Jan 2024, 19:21 I can also see that it's giving over 20% of load to the system all the time. I leave it running since I've flashed it, no further devices connected - just a blank board with LAN and power connected to it (as I'm still waiting for the DACs). It's always over 20% - up to 30%.
Code: Select all
GET_CONFIG support to read the initial values, configured presets and range setting
[<taskname>#preset<X>] : The configured preset <X> value (range checked)
[<taskname>#initial0] : The configured initial output 0 value
[<taskname>#initial1] : The configured initial output 1 value
[<taskname>#range] : The configured range setting 5 or 10
Code: Select all
GET_CONFIG,[WZ_SZ#initial0]
Code: Select all
Command unknown: GET_CONFIG,5.000
Code: Select all
[WZ_SZ#range]
Code: Select all
Command unknown: 10
- The plugin won't accept a voltage value > 10V in the commands (or > 5V when configured for 0-5V range). And a preset value is also checked for the same range when applied.localhorst wrote: ↑28 Jan 2024, 00:42 What I also haven’t tested yet: what if we command for example 20V?
Fine! And now I've been brave enough to test with commanding 11V - which ended just like you told me: "command unknown" and no action on the DAC.
Tested it with the option "Restore output on warm boot" checked on both DAC:
So it does not fall back on the configured initial settings (in my case: 5V)
OK, final decision:localhorst wrote: ↑28 Jan 2024, 17:39Had some trouble with MQTT (all commands ended up at the first DAC), but solved it now with the presets for the second DAC (Kinder).
Code: Select all
on MQTT_ioBroker#WZ_SZ_Switch do
WZ_SZ.gp8403,volt,0,%eventvalue1%
endon
on MQTT_ioBroker#Kueche_Switch do
WZ_SZ.gp8403,volt,1,%eventvalue1%
endon
on MQTT_ioBroker#Kinder_Switch do
Kinder.gp8403,volt,0,%eventvalue1%
endon
on MQTT_ioBroker#Spare_Switch do
Kinder.gp8403,volt,1,%eventvalue1%
endon
I explicitly tested that scenario, so will have to re-check thatlocalhorst wrote: ↑29 Jan 2024, 14:51 On a cold boot (unplugged power, waited, plugged in again): it switches to the values who have been set before as wellSo it does not fall back on the configured initial settings (in my case: 5V)
It's the Home Assistant (openHAB) MQTT controller.
Yes, I tried it in several ways, but was not able to get it working. From which ever side its coming, maybe ioBroker.
I'll double check and leave it unplugged a little longer.
Left the whole device unplugged from power like 10 Minutes - still returning to the values set before, not falling back.
Is the ethernet cable also unplugged? Possibly it's keeping the ESP 'warm', in that it retains enough power to keep the Flash content alive.localhorst wrote: ↑29 Jan 2024, 15:46Left the whole device unplugged from power like 10 Minutes - still returning to the values set before, not falling back.
Done it without the LAN cable plugged.
Something is keeping at least the DACs warm. Even after a longer time, I can still measure some voltage output (0,01 - 0,2V).
I'll check after testing, once the device is online again.
Publish Retain Flag is not checked.
Hehe, yes! MQTT Import plugin deactivated - this is the only trigger for the rules - and it works!
Installed, tested: unfortunately still 2V for Kinder.Ath wrote: ↑29 Jan 2024, 23:27Edit: Fix is pushed to GH https://github.com/letscontrolit/ESPEas ... 7703406625
Code: Select all
gp8403,preset,0,2
Users browsing this forum: No registered users and 0 guests