Feature Request: Enable one or more A/D inputs already on the STM8S

[nielsonm236]

A request was made by email to enable one or two A/D inputs already on the STM8S. I've always resisted this because it requires modifying the HW-584 by removing a couple of resistors if present (BR4 and/or BR5), then attaching wires to enable connection of the A/D inputs. This requires some skill to avoid damaging the HW-584. The requestor seems to have this skill, so I will look into the request more closely. (Note to self: email 3/5/2024).

The basic concept:
Attach wires to the two pads pointed to by the arrows in this picture.

Bring those wires out to an externally accessible pin or connector. How this is done will have to be left up to individual preference.

Firmware will collect data from the A/D connected to those pins and will report it as a sensor value in a Home Assistant MQTT payload. For now I'm not planning any reporting via the Browser GUI.

Add a checkbox in the GUI to enable use of the pins as A/D inputs. This is necessary so that the float protection pullup is removed from the pins with the assumption that the user has implemented appropriate external circuitry.

The A/D on the STM8S only measure voltages from 0 to 3.3V, so the user would have to build their own hardware to make sure they protect the input from over/under voltage, and would require a divider scheme to re-range voltages that exceed those limits. Not rocket science, but they need to know what they are doing. Whatever appears on the pin could then be sent to a requestor via MQTT. Then the user would need to write their own MQTT integration (in Home Assistant or Domoticz) to interpret the value into human readable form.

[nielsonm236]

A prototype of this function is in test now. If anyone wants to participate in test (in addition to me and the requestor) respond on this Issue. No GUI at this point, just a bare bones test prototype.
Some notes and anomalies:

• The default measurement period is 5 seconds, but URL command /7a allows this to be changed. I've set it to 100ms and everything runs, but I don't know if samples are being missed. The /7a format is "/7axxxxx" where xxxxx is the measurement period in ms. You must enter all 5 digits padded with 0, for example 200ms must be entered as 00200. Also, the resolution of the timer function I'm using is 100ms, so the two least significant digits are ignored, and entering 00000 will result in the minimum of 100ms.
• The payload sent to MQTT is 4 digit decimal text, with a range of 0000 to 1023. This is due to the ADC being a 10 bit converter.
• Anomaly: In my test setup I noticed that if I ground the ADC input I get a value of 91. I suspect some ground offset of about 0.3 volts, and may just be an artifact of my test setup Since this can all be calibrated in external software I'm not sure it matters. When I tie the ADC input to 3.3V I get a value of 1021.
• I'm using the HA MQTT code as the baseline and had to remove the PCF8574 functionality and Linked Pin support to make room for the ADC. So, we end up with a new firmware type for this. Those two functions are not widely used so I don't think that is a big tradeoff for a separate build with ADC functionality.
• Soldering wires to those tiny little pads is a challenge. My test setup is not pretty, but works.

Possible improvement: When the ADC period is set to 100 ms MQTT gets flooded with messages. Each ADC input produces a message every 100ms, so that's 20 messages per second, even if the inputs are not changing. A possible improvement is to only send a message if the input changed from the previous sample, perhaps with a minimum transmit period of 5 seconds (or 10 or 20 ... something just to maintain confidence it is working). This would minimize messaging when the inputs are static, and maximize messaging when the inputs are changing. I'm still not sure how we'll make sure we aren't over-running the transmit queue when messages are attempting 100ms refresh periods.

[nielsonm236]

Until the requestor is ready to perform Beta testing I will withhold this feature from general release.
Note to self:
An ADC specific build for use of this device is required, similar to the way that the BME280 is handled.
For Beta there is no GUI. All device settings are handled via URL commands. A URL command is used to display ADC measurements.