Setting numeric values through bosch_cli fails

[fetzerch]

First of all, thanks for this awesome library!

I was about to test if adapting /heatSources/energyMonitoring/correctionFactor would get the energy recordings closer to what I measure with an extra sensor at the gas meter.

Unfortunately modifying numeric values (as in "type": "floatValue") with bosch_cli currently silently fails. The following command just seems to run ok - at least \r\n doesn't look like an error:

$ bosch_cli put ... --path /heatSources/energyMonitoring/correctionFactor 1.2
...
2022-04-13 21:19:39 INFO (MainThread) [bosch_thermostat_client.bosch_cli]
Put succeed: /heatSources/energyMonitoring/correctionFactor         
"\r\n"

But then the next query just returns the old value again:

2022-04-13 21:26:13 INFO (MainThread) [bosch_thermostat_client.bosch_cli]
Query succeed: /heatSources/energyMonitoring/correctionFactor
{
    "id": "/heatSources/energyMonitoring/correctionFactor",
    "maxValue": 1.3,
    "minValue": 0.7,
    "recordable": 0,
    "type": "floatValue",
    "unitOfMeasure": " ",
    "value": 1.0,
    "writeable": 1
}

The reason seems to be that the value passed as shell parameter (str) is just directly added to the JSON which is sent to the system. Modifying the script to convert value to float yields the expected result:

2022-04-13 21:26:10 INFO (MainThread) [bosch_thermostat_client.bosch_cli]
Put succeed: /heatSources/energyMonitoring/correctionFactor
true

Note that now the response is true instead of \r\n and also query shows the updated value:

2022-04-13 21:26:13 INFO (MainThread) [bosch_thermostat_client.bosch_cli]
Query succeed: /heatSources/energyMonitoring/correctionFactor
{
    "id": "/heatSources/energyMonitoring/correctionFactor",
    "maxValue": 1.3,
    "minValue": 0.7,
    "recordable": 0,
    "type": "floatValue",
    "unitOfMeasure": " ",
    "value": 1.2,
    "writeable": 1
}

I'm not comfortable enough with the codebase to suggest a fix. I guess the safest would be to perform an internal query first, read the type and perform the conversion accordingly.

[pszafer]

Maybe I will add valueType: float | int | str as another option to pass?

[fetzerch]

The JSON specification doesn't differentiate between int or float, and a quick grep in the JSON files in the repo shows only int type. But, there are also some custom types like switchPoints. I'm wondering if it would make sense to just expect the user to pass in JSON compatible data and pass the argument via json.loads.

Then stuff like 1.0, '"some string value"', '[{"dayOfWeek": "Mo", "setpoint": "on", "time": 330}, ...]' should work. What would be a little uncomfortable is that neither stringvalue works (missing quotes) nor "string value" (shell eats quotes). But you can could catch the json.loads exception and tell the user that the datatype must be json.

[pszafer]

Fixed in 0.18.