Analog output 0-10V?

[localhorst]

Thank you TD-er, I'll check which ones are suitable. There are not so many available, it seems.

For Ton:
Checked in 1V steps, also the preset format works fine:

Code: Select all

gp8403,preset,2,10V

As well as:

Code: Select all

gp8403,volt,2,10

More testing to be done, as well as adding more DACs - but for now the kids need to go to bed.

[TD-er]

[...]
More testing to be done, as well as adding more DACs - but for now the kids need to go to bed.

Just ask them if you're allowed some more time playing...
I guess they will grand you some extra playing time as long as you ask it nicely

[localhorst]

For sure - and they are extra generous if I allow more media time for them.

[TD-er]

Maybe sweeten the deal with a bowl of chips and some drinks.

[localhorst]

Testing from ioBroker looks already pretty fine:

Bildschirmfoto 2024-01-25 um 23.03.26.png (187.18 KiB) Viewed 4209 times

doing with these rules:

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

Multimeter agrees.

Now I'm wondering how I'll adress the second DAC.
Do I have to go through the cmd MQTT?

[TD-er]

Add the taskname with a dot before the command

So for what you have now as I can't see the name of the other task in your screenshot

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

N.B. You should use the task name. I noticed you had named the taskvalue name equal to the taskname, which is allowed. But it may appear a bit confusing here when explaining it

[localhorst]

For now I made it this way. Without rules, MQTT_import, and I can directly command different devices (I guess what you desperately tried to explain to me ):

Bildschirmfoto 2024-01-25 um 23.57.54.png (132.33 KiB) Viewed 4198 times

Add the taskname with a dot before the command

Ah, nice as well, thank you!

But I guess the direct MQTT command would be the slimmest solution?

Code: Select all

WZ_SZ.cmd_arg3/gp8403/volt/0

[TD-er]

The taskname prefix should be part of the command.

So something like this:

Code: Select all

cmd_arg3/WZ_SZ.gp8403/volt/0

[localhorst]

The taskname prefix should be part of the command.

It seems it doesn't work in ioBroker (or I'm too dump to do it correct again). Response is always "command unknown".
But it works just like on my last screenshot. Well, let's see once I have the second DAC connected.

[localhorst]

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

One more question, regarding moving away from GPIO-4:
Where can I move to?

Bildschirmfoto 2024-01-26 um 11.35.33.png (2.31 MiB) Viewed 4076 times

And what do the mean? I guess to avoid using them?

Bildschirmfoto 2024-01-26 um 11.37.41.png (281.71 KiB) Viewed 4076 times

If I avoid the and try to stay on the right side of the board (GPIO-2, 4, 12, 14, 15) - it seems that I don't have any choice?
Or is it safe to move to GPIO-32 (CFG) and 33 (485_EN)? From the documentation it looks just fine.

[Ath]

As your board doesn't seem to contain hardware for RS485, you should be able to use GPIO32 and GPIO33 just fine.

[TD-er]

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".

[localhorst]

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".

Everyday learning with ESPeasy - lesson X.

As your board doesn't seem to contain hardware for RS485, you should be able to use GPIO32 and GPIO33 just fine.

Bildschirmfoto 2024-01-26 um 14.03.38.png (184.48 KiB) Viewed 4019 times

Set GPIO32 and GPIO33 - gorgeous - works like a charm.
Now I've set the 2nd DAC with the dip-switches to I2C 0x58 address - connects right away and doing its job.
MQTT connection working without problems as well.

Bildschirmfoto 2024-01-26 um 14.11.56.png (204.67 KiB) Viewed 4019 times

Next:

• soldering the Y cables to connect both DAC at the same time - and already for final assembly
• designing / printing some spacers for the power board, to lift it above the DACs - then everything will fit into this housing

Ton - no hardware arrived yet?

[Ath]

Ton - no hardware arrived yet?

It arrived today while I was at work, so I'll be playing with it tonight

[Ath]

Been testing, and besides like 0.5% offset (to be expected, 2 multimeters don't even agree ) it works like a charm, so I'm happy with the result so far.

Any feedback or requests?

I might change the default I2C address to 0x5F as that seems to be the default.

[localhorst]

Been testing, and besides like 0.5% offset (to be expected, 2 multimeters don't even agree ) it works like a charm, so I'm happy with the result so far.

Very nice, just like me.

Any feedback or requests?

For the moment, it seems all just fine - it was already pretty straight forward from the beginning.

I might change the default I2C address to 0x5F as that seems to be the default.

That's a good idea! Saves people like me to see it not working in the first shot.

Which GH Actions run will contain your changes? I'd like to test "Send out data for events/controllers when changing output values"

*edit*
One comment, just cosmetics, but:

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'd leave the sorting as it was for a better overview. The goal is already reached by PLUGIN_SET_DEFAULTS set to 0x5F,

[TD-er]

[...]
*edit*
One comment, just cosmetics, but:

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'd leave the sorting as it was for a better overview. The goal is already reached by PLUGIN_SET_DEFAULTS set to 0x5F,

Hmm someone is getting familiar with the code too
I totally agree with the suggested change.

[localhorst]

Well, some basic understanding and programming skills, so very interesting how you do it.
And I'm curious and really appreciate your work - implementing the solution for the output so fast (and first shot already really good implemented) - it's really fun with you guys.

Now I have to get my caliper, fire up FreeCAD and create my adapter plate to get the components clean fitting in the housing, ending up in a nice, solid unit. As a core piece of my ventilation automation in the end.
Unfortunately the model is only available as STL - so I cannot work directly on it or modify it. So I'll make some kind of adapter plate / insert.

[TD-er]

Most software can import STL files.
Sure it doesn't have the basic components or editable individual dimensions you can adapt, but it is for sure easier to work on an existing template.

[localhorst]

Yes, you can import STL. But you cannot really change or adapt something. Even measuring is hell with its triangles. STEP would be way better.

*edit*
Ok, got it converted to a solid

More than 20 years experience with Catia V5, but still pretty new to FreeCAD. But I really like it and I'm surprised how powerful it is!

[TD-er]

It depends highly on how it has been exported.
Sure you can define cylinders, cubes, etc in STEP, but you can also define lots and lots of triangles.
And believe it or not, there is software that later added STEP export which just generates STL and translates it into STEP syntax.

It is like turning a text in some font into individual vectors.
You know what I mean, as that's also done by a lot of software when generating other formats like PDF etc.
For fonts there is also a logical reason for it and that's copyright and licenses of fonts.
For lazy exports into STEP or 3MF or any other "better" format, there is no other excuse than lazyness or just being cheap as a software vendor.

[Ath]

[...]
*edit*
One comment, just cosmetics, but:

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'd leave the sorting as it was for a better overview. The goal is already reached by PLUGIN_SET_DEFAULTS set to 0x5F,

Hmm someone is getting familiar with the code too
I totally agree with the suggested change.

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 ).
I'll put the list back in the original order.

[Ath]

Like this:

Screenshot - 27-01-2024 , 14_57_23.png (14.68 KiB) Viewed 3745 times

[Ath]

Which GH Actions run will contain your changes? I'd like to test "Send out data for events/controllers when changing output values"

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).

Edit: Updated Actions run URL
Edit2: Updated Actions run URL again
Edit3: Updated Actions URL to Runs overview, because of multiple updates

[localhorst]

Very nice - looking good!

• [P166] Send out datat for events/controllers when changing output values
• [P166] Send out data by scheduling a timer

Functioning right away, when setting the interval back to 0 sec.

0x5F as standard as well as the sorting of the addresses: right on.
Not tested yet: 0-5V feature.

The "Initial value output" setting is nice as well: I've set it to 5V - which will set the ventilation to the lowest level / 25% with heat recovery.
When do you think this plugin will make it into a release? From my feeling, there is not so much left to do.

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.

[Ath]

Very nice - looking good!

Great

When do you think this plugin will make it into a release? From my feeling, there is not so much left to do.

There is still the documentation to do, that's also part of the repository, so only after completing that it should/will be merged.

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.

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.

[Ath]

Not tested yet: 0-5V feature.

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

[localhorst]

Fine!
What I also haven’t tested yet: what if we command for example 20V?

Adapter plate does its job:


Now cables need to be finalised.

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%.

Fun fact: the load is now, since the DAC is connected, always between 10 and 20%.

[localhorst]

Just testing:

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

If I try:

Code: Select all

GET_CONFIG,[WZ_SZ#initial0]

I get:

Code: Select all

Command unknown: GET_CONFIG,5.000

And 5 is correct.

This:

Code: Select all

[WZ_SZ#range]

Is giving this:

Code: Select all

Command unknown: 10

10 is correct as well.

But every time "Command unknown". Something needs to be fixed in the code or is it me, who is doing it wrong?
I'm doing it via --> Tools --> Command

[Ath]

Ah, yes, that might be a bit confusing because of the way I wrote that down.
The commands are quite straight forward, as you already found out, but the 'GET_CONFIG' values I've named that way as they can be retrieved from a plugin via the 'PLUGIN_GET_CONFIG_VALUE' function, similar to 'PLUGIN_INIT', 'PLUGIN_EXIT', etc.
'PLUGIN_GET_CONFIG_VALUE' is used during Rules processing & variable replacement, to replace the '[<taskname>#<valuename>]' syntax for inserting the values of a plugin, but if the '<valuename>' part isn't found, the 'PLUGIN_GET_CONFIG_VALUE' function is called, to see if that is implemented in the plugin. Besides a value, it should also return 'success = true' for a supported value. This function is actually an extension of the values of a plugin, as that is limited to 4 values.
Advantage of the Values is that these can be, easily and automatically, sent via a Controller, and their names can be changed by the user.
Advantage of the GET_CONFIG values (as I call them affectionately) is that there can be as many as you need.
Advantage of them being available via the '[<taskname>#<valuename>]' notation is that the value can be formatted as desired via the available formatting options.

Testing like you did via the Command is actually how I usually test them, so I don't have to edit a rule, just for testing a few of these values
The Command unknown is a (usually) harmless side-effect of that, unless they return text/commands... You might want to look up the 'reset' command before actually testing it! It acts immediately, without any prompt or warning, wiping the entire configuration of the unit

[Ath]

What I also haven’t tested yet: what if we command for example 20V?

- 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.
- The library code (and chip) only has 2 ranges, 0-5V and 0-10V, and it calculates a 12 bit value by dividing the max. value by the presented value and shifting the result left by 4 bits, in a 16 bit variable (uint16_t).

This guarantees that the absolute max. output voltage supported is never exceeded beyond the set max. value +/- any (0.5%) accuracy/margin.

The UI allows for preset values to be configured between 0.000V and 10.000V, but, as noted above, when applying such value it will return 'Command unknown' (== invalid argument) for values out of range (set to 0-5V and apply a value > 5.0V).

[localhorst]

Ah, ok, thank you, so the GET_CONFIG section is working as intended.

The plugin won't accept a voltage value > 10V in the commands (or > 5V when configured for 0-5V range).

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.

Meanwhile I've finished the hardware and cable setup:

IMG_2811.jpeg (3.36 MiB) Viewed 3387 times

Now it is in its final stage and both DACs are working.
Had some trouble with MQTT (all commands ended up at the first DAC), but solved it now with the presets for the second DAC (Kinder).

Bildschirmfoto 2024-01-28 um 17.35.28.png (235.78 KiB) Viewed 3387 times

Now some double checking, if nothing negative pops up, I guess it can start production next week in my server cabinet.

[Ath]

I've added a setting:
"Restore output on warm boot" (enabled by default when adding the plugin) to apply the last set value when the ESP reboots. On cold boot (powering on or after pressing the reset button) the configured initial values will be applied.

and a command:
- gp8403,init,<ch> : Set the initial voltage to channel

Now I can start writing the documentation

[localhorst]

Perfect, that's a good idea / setting!
Installed it already, will test tomorrow - good night!

[localhorst]

I've added a setting:
"Restore output on warm boot" (enabled by default when adding the plugin) to apply the last set value when the ESP reboots.

Tested it with the option "Restore output on warm boot" checked on both DAC:

• On a warm boot (reboot via tools): it switches to the values who have been set before = good
• On a cold boot (unplugged power, waited, plugged in again): it switches to the values who have been set before as well

On cold boot (powering on or after pressing the reset button) the configured initial values will be applied.

So it does not fall back on the configured initial settings (in my case: 5V)

[localhorst]

Had some trouble with MQTT (all commands ended up at the first DAC), but solved it now with the presets for the second DAC (Kinder).

OK, final decision:
I returned back to use the MQTT Import plugin with rules, as this just feels cleaner in ioBroker and in general.
Settings in MQTT Import:

Bildschirmfoto 2024-01-29 um 15.00.35.png (141.94 KiB) Viewed 3092 times

Rules:

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

In ESPeasy:

Bildschirmfoto 2024-01-29 um 15.03.06.png (235.42 KiB) Viewed 3092 times

In ioBroker:

Bildschirmfoto 2024-01-29 um 15.04.01.png (227.3 KiB) Viewed 3092 times

[Ath]

The WS_SZ. and Kinder. prefixes have to be included in your MQTT commands for gp8403, just like you have in the Rules, then it should work as intended. But maybe the Controller does something special to the command-content when having a period included, will have to check. What Controller do you have configured (I missed that info I guess)?

On a cold boot (unplugged power, waited, plugged in again): it switches to the values who have been set before as well

On cold boot (powering on or after pressing the reset button) the configured initial values will be applied.

So it does not fall back on the configured initial settings (in my case: 5V)

I explicitly tested that scenario, so will have to re-check that

[localhorst]

What Controller do you have configured (I missed that info I guess)?

It's the Home Assistant (openHAB) MQTT controller.

The WS_SZ. and Kinder. prefixes have to be included in your MQTT commands for gp8403, just like you have in the Rules, then it should work as intended.

Yes, I tried it in several ways, but was not able to get it working. From which ever side its coming, maybe ioBroker.
Without WS_SZ. and Kinder. prefixes it works - but only the first DAC will be switched - logically.

But it works perfect like I posted it before with MQTT Import and the rules. And also looks very clean in ioBroker.

I explicitly tested that scenario, so will have to re-check that

I'll double check and leave it unplugged a little longer.

[localhorst]

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.

[Ath]

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.

You could try what happens if you pull the EN pin to ground for ~ 1 sec., that should be the reset, and that's what I tested

[TD-er]

Are the values published to the broker with the retain flag present?
If so then the last values will be sent again to any MQTT client subscribing to the topic.

[localhorst]

Is the ethernet cable also unplugged?

Done it without the LAN cable plugged.

Possibly it's keeping the ESP 'warm', in that it retains enough power to keep the Flash content alive.

Something is keeping at least the DACs warm. Even after a longer time, I can still measure some voltage output (0,01 - 0,2V).
So I guess, maybe from the power board, some Elko / capacitor is still giving some juice.

Are the values published to the broker with the retain flag present?

I'll check after testing, once the device is online again.

[localhorst]

Even after unplugging the + completely from the power board, I can still measure some output.
So it have to be the DACs keeping some juice, no capacitor on the power board.


After powering up - returning to the settings from before.
Maybe I’ll leave it off power for the whole night and see tomorrow?

[localhorst]

Are the values published to the broker with the retain flag present?

Publish Retain Flag is not checked.

[Ath]

Just re-tested, but here it works as intended.
My testing procedure:
- Plug ESP32 16M board with MAX_16M8M_LittleFS build and GP8403 board into power (task already was enabled)
- No controller configured on the plugin, nor any rules to change the output values
- Output0 configured for initial value 2V, Output1 configured for initial value 7V
- Check devices page if Output0: 2V and Output1: 7V are shown: Yes (== as expected)
- Using command "gp8403,preset,0,jk" to change Output0 to 10V
- Check devices page if Output0: 10V and Output1: 7V are shown: Yes (== as expected)
- Pull power from ESP & GP8403 board for ~ 10 seconds
- Plug ESP and board back into power
- Wait for unit to boot (few seconds), select the Devices page, showing Output0: 2V and Output1: 7V (== as expected)
- Using command "gp8403,preset,0,jk" again to change Output0 to 10V
- Check devices page if Output0: 10V and Output1: 7V are shown: Yes (== as expected)
- Click the Reboot button on the Tools page
- Wait for the unit to reboot, and show the Main page
- Select the Devices page, showing Output0: 10V and Output1: 7V (== as expected)

Is there a possibility that one of the rules you have active is changing the output values? Like the MQTT Import and rules you showed earlier?

[localhorst]

Is there a possibility that one of the rules you have active is changing the output values? Like the MQTT Import and rules you showed earlier?

Hehe, yes! MQTT Import plugin deactivated - this is the only trigger for the rules - and it works!

But:

Bildschirmfoto 2024-01-29 um 22.56.37.png (235.11 KiB) Viewed 2881 times

They all should show 5V - except for "Spare" - 0V is set for this = ok.
This is weird - Kinder is definitely set to 5V. But coming up only with 2V. Tested some scenarios (e.g. different initial value / different voltage before shut off, etc) - but always 2V

[Ath]

Ah, that's a hint for a bug. When the plugin settings are saved, the state flag for restoring the previous value should be reset. It should also be fixed when forcing a hardware reset/power cycle on the device.

Edit: Fix is pushed to GH https://github.com/letscontrolit/ESPEas ... 7703406625

[localhorst]

But besides a possible bug: when the MQTT Import and rules are active, it'll be always just like ioBroker needs it to be. Directly synchronized after booting. Good for me.

[localhorst]

Edit: Fix is pushed to GH https://github.com/letscontrolit/ESPEas ... 7703406625

Installed, tested: unfortunately still 2V for Kinder.
With deactivated MQTT import having all channels on 10V, power off, wait, power on - 2V instead of 5V for Kinder. Same picture as above.

[localhorst]

Wait, wait, wait!
Now I've set "Spare" to initial 5V as well. Tested again, coming up with all 5V except for Kinder still 2V.
Looked back in ioBroker and found this from testing:

Bildschirmfoto 2024-01-30 um 00.07.59.png (287.77 KiB) Viewed 2803 times

This cmd is containing:

Code: Select all

gp8403,preset,0,2

and going besides the MQTT Import plugin, kicking in right after booting and is responsible for the value 2V.

Emptied the cmd in ioBroker and checked again: all fine and like it should be.
Sorry for giving you a headache!