Encapsulate response in data point

[s0170071]

I tried your lib for the better part of the week now and I keeps troubling me, I have to admit. Using callbacks adds a lot to complexity and so does the nature of the data points. Variant type is a nice trick but not self-explainatory.

My suggestion: make the data points self-sustained. What I mean with that is that all the conversion as well as the result, the callback and so on would be with the datapoint object. It does have all the info it requires.

class vitoDPstruct2 {
public:
    const uint16_t address; // obvious
    const EnumDataType dataFormatType;  // TempL etc...
    String value; // thats the value of the data point
    boolean InitiateReadFromHeater(boolean blockingMode)
    boolean InitiateSendToHeater( boolean blockingMode)
    void* callbackOnResultUpdate()
    const EnumReadWrite ReadWrite;  // read-only or read-write
    const EnumSensorType sensorType; // thats for Homeassistant auto-discovery
    const char* UoM;  // unit of measurement : thats for Homeassistant auto-discovery
    const char* sensorTypeTopic; // mqtt topic  
    const EnumPriorityType priority;  // I have two queues: read with priority every 10s or  read every 100s or  disable

Improvements would be:

• less type complexity by using String as result. I mean, we're not doing anything here with the numbers, they are almost certainly shipped of to a MQTT server or via html. Both require string ultimately.
• The conversion can be handled with the information thats inside the data point. No Case statement in the callback function.
• the callback function receives a pointer to the data point that has been updated. By then, the result should already be available in "value"
• optional: blocking mode... well, it has its merits. If you have multiple interfaces, e.g. html or mqtt or serial, each would need have its own callback and then you need to introduce semaphores and.... its just a mess. Hence my question about a busy indicator the other day.
• maybe the each DP should have its own call back pointer. Then I can set up all the DPs that are probed round-robin for mqtt and whenever they are updated, they invoke the pubsub subroutine. The temporary htmp DP on the other hand could get its own call back sending the html response on update.
• I also have DPs that write ESP pins. They are of type ESPIO and their address is the pin number. Again, a DP specific callback is welcome.

by datapoits definition looks like this:

   const vitoDPstruct2 DPoints2 [] = 
    {
    // Name             ,           Adress, Type ,   Read/Write , SensorType, UoM, binary sensor  https://www.home-assistant.io/integrations/sensor/ https://www.home-assistant.io/integrations/binary_sensor/
    {"VitoOnOff",                   0x000c, na,        RO , EspIO,       ""       , "switch" , low  },  // ESP IO port pins
    {"EVU",                         0x0004, na,        RO , EspIO,       ""       , "switch" , low  },  // ESP IO port pins
    {"Betriebsmodus",               0xb000, Mode,      RW , None,        ""       , "sensor" , low  }, 
    {"Geraetekennung",              0x00f8, CountS,    RO , None,        ""       , "sensor" , disabled  },  
    {"Betriebsmodus",               0xb000, Mode,      RW , None,        ""       , "sensor" , low  }, 
    {"ManuellerModus",              0xb020, Mode,      RW , None,        ""       , "sensor" , low  }, 
    {"LeistungDurchlauferhitzer",   0x7907, Mode,      RW , None,        ""       , "sensor" , low  }, 
    {"Freigabe_WasserElektro",      0x6015, Mode,      RW , power,       ""       , "binary_sensor" , low   }, 
    {"Freigabe_HeizenElektro",      0x7902, Mode,      RW , power,       ""       , "binary_sensor" , low   },  

what do you think ?

[s0170071]

Fwiw, I can do that myself by putting your lib inside a struct of mine. So if you just want to close this, its okay for me :-)

[bertmelis]

Everything is possible. But I also try to keep the library lean. In the end, I made the API like I use it. That doesn't mean I'm not open to suggestions and changed. Especially if it doesn't impact the way it works now.

Adding a blocking method is trivial. I'll put it on the list.

A custom callback for each DP is doable but more easily done by user code. Nothing withholds you from changing the callback for each request. I'll create sample code in the readme. Could be done cleanly with a blocking call.

Binary type to string conversion is something that I found ugly when done in the library. Should be done in the callback imho. I didn't find a clean solution that suited all datatypes.

I think a lot of the code spaghetti comes from the fact that you have to work with callbacks. That I can easily solve.

Question: how should the function signature of a blocking call look like? What should it return? What in case of an error?

[bertmelis]

To be tested in branch: https://github.com/bertmelis/VitoWiFi/tree/return-written-data