Hi @nh.schottfam, (in CC to: @Matthew@thebearmay)
I would lik to ask you for assistance regarding of the OpenWeatherMap - ultravioletIndex value in webcore that possibly is not defined as decimal. While I'm checking the value directly on device page of OpenWeatherMap it showing me ultravioletIndex: 1.73 but in case I'm trying to get the same data via webcore it get value 1.
Here is an example of piston and appropriate logs (full). Currently both value are 0 because in my country is 7:00 pm.
@nh.schottfam is correct. HE does define ultraviolet index as a 'NUMBER' (aka an integer) . This driver accepts the OWM datatype that includes decimals (BigDecimal). Technically my driver should
either not use the ' UltravioletIndex' capability, or it should force it to an integer to be compliant with the HE definition.
I don't plan of changing anything in the driver, for now, as it it does seem to provide a greater accuracy (more decimal places) based in what OWM provides. However, it does not appear that WebCoRE is incorrect in forcing the UltravioletIndex to an integer as HE requires.
For the long term the solutions could be 1) HE changes it's UltravioletIndex capability to allow decimals; 2) I change the driver to be compliant with the integer requirement (potentially taking OWM's reported decimal number and rounding it instead of just truncating it) or 3) OWM changes it's reporting to be a integer (then the issue goes away).
Even if I do #2, it would still not always match WebCoRE as WebCoRE accepts just the integer portion and truncates any left over decimal. In the example originally raised it takes what OWM provides (1.73) and truncates that to 1. If I were to change the driver I would be inclined to round that to 2.
While my driver is technically wrong, I do not intend to alter it at this time. Either result ('1' or '2') would be less accurate than that is presently presented. If I did change it I would round the number OWM provides and that still would not line up with WebCoRE half the time.
