@LarryME,
All good thoughts. But let’s push down a level on each of these.
- Generic on / off data, especially lagged and possibly packetized, isn’t good enough for current mostly-unsupervised machine learning at Sense AFAIK. Maybe in the future if Sense starts doing more supervised learning. And quite honestly, I don’t believe NDI has worked all that well exactly for that reason.
- Your Alexa and Ecobee examples aren’t really valid. Alexa’s a whole different bird, not related to machine learning. And the Ecobee data is only used on the back-end for very specific model development, HVAC, not direct machine learning, because it is only every 5 min sampling. That’s why the integration is called Ecobee Historic - because it isn’t realtime. I guess that Sense could pull historic data from SmartThings as well, but the HVAC was targeted because it is such a big, and yet tricky to detect, consumer of energy (especially heat pumps and mini-splits). I can understand why Sense, that had a choice of a grabbag of data from a hub, vs highly targeted data for one specific set of model types, I would pick the latter.
- I don’t have anything against SmartThings. Just pointing out what works today and what doesn’t, and the thing that has worked is hub developers that are willing to integrate to Sense using existing hooks. There are also some technical constraints that limit SmartThings, given the current Sense capabilities - communications protocol used by many of SmartThings IoT device (Zwave, ZigBee) and the total mixed bag of incoming data.
Not trying to be an apologist for Sense, but rather inject a little bit more logic and technical info into why some integrations might be harder or less useful than others.