The ability to merge the same device separately with more than one other device would be useful. Using the voice recognition analogy it would be like identifying different conversations with the same person, for example Harry having a conversation with Sally would be different than Harry having a conversation with Tom.
This ability to identify separate ‘conversations’ would be useful for those of us with heat pumps. Heat pumps are frequently paired with other components to accomplish separate tasks such as heating one zone of a house vs another vs heating domestic hot water. Different groups of components (e.g. circulation pumps or fans) switch on- talk to the same heat pump- depending on the task.
@mbgracz, I have thought similarly from time to time, for even a simpler case, my lowly furnace fan. In the summer, it is part of my AC, in the winter, it’s the main show. But that means more than multiple associations - it means that it is conditionally associated with different devices part of the AC when that is running, part of virtual device, “the Furnace” when the AC is not running. I suspect your goal is similar ?
Yup. In database management this type of relationship is referred to as a one-to-many relationship. I asked Sense if it was possible, but didn’t get a clear answer. When I went to try and merge some pumps with a heat pump, I realized that it wasn’t. Maybe not a common use case, but one must remain hopeful!
@mbgracz, my point was that this is beyond a one-to-many relationship. In my case, the simple furnace fan, there are two important tricks that are beyond the simplistic one-to-many relationship between detected devices and actual devices.
In the furnace fan case, Sense would need to construct an additional virtual device, Furnace, so that the real Furnace device could be associated with the virtual device Furnace as well as my AC.
All the power usage, statistics and bubble display associated with the composite devices (in my case AC and the Virtual Furnace) would have to be conditional. One only wants the Furnace Fan to count towards AC usage when the AC compressor is on, and toward the virtual Furnace when the AC is off. To put it differently, I don’t want an AC bubble popping up when the Furnace Fan comes on in the middle of winter. The conditional usage pre-supposes an accurate master indicator of which top-level device is using the underlying component device(s). In my example it’s tricky since there is no master Furnace device (Sense detects the whole gas furnace as the Furnace Fan).
I suspect that’s how you would want this Wishlist feature to work. Otherwise you would have multiple devices, that share the same components, pop up as bubbles based on a detection, when they should be mutually exclusive.
I dunno how the Sense engineers construct the Merge code, but assuming that all relevant devices could be identified uniquely, and in less than a week almost all of them have been, then somewhere could a layer of code something like this be added?:
Merge 1 = (Iff On devices = Heat Pump AND GarageCircPump AND GarageCircPump1) then NewDevice = Garage heat;
Merge 2 = (Iff On devices = Heat Pump AND HouseCircPump AND CAFFan) then NewDevice2 = House heat;
and maybe:
Merge 3 = (Iff On devices = Heat Pump AND GarageCircPump AND GarageCircPump1 AND HouseCircPump AND CAFFan) then NewDevice3= HouseAndGarage Heat
I don’t work firm Sense, but I do think you are thinking the right way. At the same time, you are blending Sense’s two distinct merge paradigms (really 3, but 2 are almost the same)
AutoMerge - Sense creates a new device automatically out of two detections that show 100% correlation (they always turn on and off together). This paradigm is still a little tricky because Sense occasionally gets it wrong and there is no easy recourse to fix (not undoable by user)
Manual Merge - Rolls one or more additional devices into an EXISTING device. Undoable by the user.
You’re talking about a much more complicated kind of merge, but useful.