Closed hzulla closed 1 year ago
Is the position 54:56 of the hex substring correct? The other guys are reading it from 22:24. On my Judo, the values at 22:24 and 54:56 are identical, but that may be caused by my system configured to use dH as its water hardness unit.
Hi Hanno,
In my case, it was that the original value was not plausible. I had opened an issue on this in the IOBroker project to ask if it is similar for others: https://github.com/arteck/ioBroker.judoisoft/issues/27 As an answer I got from the developer a line of code where the value is divided by 2 and added with 2. The value that came out was again much more plausible for me. But whether that is now so correct, I can also not say
I will ask Judo. Their email support may answer technical inquiries, at least it's manned by humans and gave actual responses last time I had a problem with my device's cloud connection.
okay, thank you so much for taking care of this. I am curious about the answer from Judo
This is the formula for the maximum adjustable desired output hardness. See in Manual Chapter 9 - Technical data
I think that the conductance sensor from my system is no longer working correctly, since the maintenance is already half a year overdue anyway. This is replaced during the annual maintenance
Wait, which manual are you talking about?
https://github.com/www-ShapeLabs-de/Judo-i-soft-save-plus-to-mqtt-bridge/blob/9ea6f6145c0fc38f97e52bdf989079c6f3950e3e/python/getjudo.py#L231
Hi there,
again, thanks for the script. I've copied your code for my own little script and found the line above puzzling. According to it, the input hardness of my Judo device is lower than the output hardness.
Comparing your code to another project's version of the same problem, the other guys don't seem to do the
input_hardness.value = float(input_hardness.value)/2 + 2
calculation that you are doing.When I remove that added formula from my code, the result also looks more plausible and input hardness is higher than output hardness.