Closed cryptk closed 10 months ago
Below is a telemetry example for a pool with 2 BOWs and a filter that is shared between them:
"Filter": [
{
"@systemId": "3",
"@filterState": "7",
"@filterSpeed": "0",
"@valvePosition": "2",
"@whyFilterIsOn": "5",
"@fpOverride": "0",
"@reportedFilterSpeed": "54",
"@power": "387",
"@lastSpeed": "54"
},
{
"@systemId": "14",
"@filterState": "1",
"@filterSpeed": "50",
"@valvePosition": "2",
"@whyFilterIsOn": "11",
"@fpOverride": "0",
"@reportedFilterSpeed": "50",
"@power": "300",
"@lastSpeed": "1"
}
],
These are the same filter hardware, just configured as shared equipment. In that telemetry systemId 3 is connected to a pool and systemId 14 is connected to a Spa. The Spa currently has it's "filter" on, which turns on the physical filter pump, and sets the filterState for the pool filter to "7", which appears to mean something along the lines of "It's on, but only because it's shared equipment and something else that needs it has commanded it to turn on, not because this specific systemId was requested to turn on"
This might be fixed at least for shared filter pumps with the merge of #11, waiting on confirmation from a tester
I don't think we need to do anything special with shared equipment at this point. Going to close this for now.
Some pools use "shared equipment", and example is having a single filter pump that is used for both a pool and a spa. Currently, that one filter pump is represented twice, once under each body of waters device. This may be the right way to go long-term, but there is someone testing the integration now who can provide feedback.