Binding for the Alfen wallbox in work?

I just started to integrate the Alfen Wallbox via Modbus TCP/IP. This has also been discussed in the following thread:

But actually it has several challenges:

  • The Modbus binding doesn´t support reading Strings
  • The Modbus binding doesn´t support reading FLOAT64 data type values

Whereas I could easily live without reading the Strings, for which a certain solution is described, the reading of the FLOAT64 data is not resolved yet. And those parameters are quite relevant.

Does anybody work on developing a binding for the Alfen wallbox which allows a fast and smart integration for everyone?

I don´t have the knowledge to develop a binding by myself, but I would be happy to support the testing.

Don’t complain but implement this as openHAB rules yourself. Combining two 32bit values into one isn’t rocket science I have even seen posts on this here on the forum.
You should not expect or wait for anyone to start building a dedicated binding just for that purpose when there’s an alternative as simple as this.

I succeeded in the meanwhile to read out the Mode3 string in such a way that I can use it further in rules or apply a transformation on it.

rule "String zusammen setzen - Mode 3"
    when 
        Item WB_Status_Mode3_1 received update 
    then
        var Int1 = ((WB_Status_Mode3_1.state as DecimalType).intValue())/256
        var Int2 = ((WB_Status_Mode3_2.state as DecimalType).intValue())/256
        var Int3 = ((WB_Status_Mode3_3.state as DecimalType).intValue())/256
        var Int4 = ((WB_Status_Mode3_4.state as DecimalType).intValue())/256
        var Int5 = ((WB_Status_Mode3_5.state as DecimalType).intValue())/256

        var String Mode3_String = String::valueOf(Character::toChars(Int1))
        if (WB_Status_Mode3_2.state != 0) Mode3_String = Mode3_String + String::valueOf(Character::toChars(Int2))
        if (WB_Status_Mode3_3.state != 0) Mode3_String = Mode3_String + String::valueOf(Character::toChars(Int3))
        if (WB_Status_Mode3_4.state != 0) Mode3_String = Mode3_String + String::valueOf(Character::toChars(Int4))
        if (WB_Status_Mode3_5.state != 0) Mode3_String = Mode3_String + String::valueOf(Character::toChars(Int5))

        //logInfo("Wallbox: Mode3-String", "Mode3_String: " + Mode3_String + ", Länge Mode3_String: " + Mode3_String.length)
        
        WB_Status_Mode3.postUpdate(Mode3_String)
end 

But I have no clue, how I could continue with reading the FLOAT64 value. The only thing I found is the below linked post which allows to transfer a byte array to a FLOAT32 value. But how to adapt it for FLOAT64 with the most significant bit first (called “network byte order” in the Alfen manual)? Do you have a tip for the respective posts you indicated?

Apart from that, I hope, that other Alfen users can answer me the following point I wonder about.

By using Modscan, I could read out the following data for the FLOT64 registers from 362 on:
(Modscan works with an offset of 1 compared to the Alfen documentation)


According the Alfen documentation, I understand, that the registers are reserved or not available respectively. Can someone confirm that actually only the FLOT64 register “Real Energy Delivered Sum” with the starting register 374 is available?

Last but not least, I would still appreciate when reading FLOAT64 registers becomes possible with the Modbus binding directly. I understood from other posts, that there might be a lot of different ways how the registers are arranged, but looking to other tools, like Modscan, it is most probably most of the time reduced to two approaches.

I believe I succeeded in doing it. I posted my draft here in the hope that I found somebody to test it practially.

Unrelated to your 64-bit work (well done on that) -

There’s a bit of a race condition hidden here. When a block of data is read across Modbus, the binding updates individual linked Items. There is no guarantee which will be the first or last to be updated.
So there is a small risk in a rule like this of mixing ‘new’ and ‘old’ data, i.e. looking at an Item that hasn’t been updated yet.

I think it would be sufficient to just put a 50mS sleep at the top of your rule, to be sure everything got done before using related Item states.

This I guess will apply to your 64-bit work as well - make sure you are not splicing old and new data into a spurious value.

There is an elaborate way to “do it properly” and wait for all of a set to get updated, described elsewhere, but I doubt you need that complexity

Very good point! Thanks a lot for this tip.