MQTT - Flat array with plain values expanded incorrectly

[sebastianstolzenberg]

A json array with plain numbers is expanded incorrectly.

16:13:17.402 MQTT IN: go-eCharger/221889/nrg: [229.71,2.17,2.17,3.72,0,0,0,0,0,0,0,0,0,0,0,0]
16:13:17.403 Expanding json message
16:13:17.403 Plain json array was converted to hash
16:13:17.404 go-eCharger/221889/nrg/3.72 = 1
16:13:17.405 go-eCharger/221889/nrg/0 = 1
16:13:17.405 go-eCharger/221889/nrg/2.17 = 1
16:13:17.405 go-eCharger/221889/nrg/229.71 = 1

[sebastianstolzenberg]

The following change in mqttgateway.pl leads to the desired output.

diff --git a/sbin/mqttgateway.pl b/sbin/mqttgateway.pl
index 929e87df..767b8c12 100755
--- a/sbin/mqttgateway.pl
+++ b/sbin/mqttgateway.pl
@@ -431,7 +431,8 @@ sub received
                        undef $@;
                        eval {
                                if( ref($contjson) eq "ARRAY" ) {
-                                       my %tmphash = map { $_ => 1 } @$contjson;
+                                       my $key = 0;
+                                       my %tmphash = map { $key++ => $_ } @$contjson;
                                        $contjson = \%tmphash;
                                        LOGDEB "Plain json array was converted to hash";
                                }

which produces the following output:

17:12:35.471 OK: MQTT IN: go-eCharger/221889/nrg: [227.23,2.17,1.86,3.72,0,0,0,0,0,0,0,0,0,0,0,0]
17:12:35.472 Expanding json message
17:12:35.472 Plain json array was converted to hash
17:12:35.474 go-eCharger/221889/nrg/11 = 0
17:12:35.474 go-eCharger/221889/nrg/3 = 3.72
17:12:35.475 go-eCharger/221889/nrg/14 = 0
17:12:35.475 go-eCharger/221889/nrg/8 = 0
17:12:35.475 go-eCharger/221889/nrg/13 = 0
17:12:35.475 go-eCharger/221889/nrg/1 = 2.17
17:12:35.475 go-eCharger/221889/nrg/5 = 0
17:12:35.475 go-eCharger/221889/nrg/10 = 0
17:12:35.476 go-eCharger/221889/nrg/12 = 0
17:12:35.476 go-eCharger/221889/nrg/15 = 0
17:12:35.476 go-eCharger/221889/nrg/7 = 0
17:12:35.476 go-eCharger/221889/nrg/9 = 0
17:12:35.476 go-eCharger/221889/nrg/2 = 1.86
17:12:35.477 go-eCharger/221889/nrg/6 = 0
17:12:35.477 go-eCharger/221889/nrg/4 = 0
17:12:35.477 go-eCharger/221889/nrg/0 = 227.23

[christianTF]

This is the same issue as #1383

Array parsing is difficult because of the missing key in an array, and different expectations how the result should be forwarded.

The current implementation has the functionality to get/find a concrete element in an array by setting the elements to TRUE.

In an array [„orange“, „apple“, „strawberry“] it allows to find the element „orange“ on the Miniserver.
As the key is missing, and array elements don’t have a defined size (number of elements), internally creating a key (0, 1, 2,…) may lead to unexpected results if the element count changes.

Currently no idea how to handle this in a generic way.

[sebastianstolzenberg]

I see. Maybe providing both solutions in parallel is an approach that would make all of us happy. Each array could be expanded into an index based representation and into one that is value-presence based.

I.e. in my case go-eCharger/221889/nrg: [227.23,2.17,1.86,3.72,0,0,0,0,0,0,0,0,0,0,0,0] could be expanded into:

1. go-eCharger_221889_nrg_i_0 to go-eCharger_221889_nrg_i_15 containing the values at the respective indices.
2. go-eCharger_221889_nrg_v_0, go-eCharger_221889_nrg_v_3.72 and so on to indicate the presence of a value.

[christianTF]

Yes, good idea.
By disabling of forwarding, or filtering, the forwarding load to the Miniserver can be manually reduced by the user.