Feature request: mqtt and smart home integration

[drzacek]

I know this might be an ambitious one, but this is a smart watch and I'd love to see some actual smart features beside notifications and step counting.

So the way I see it, the sensor data like battery life, steps, hr etc, should be possible to export to mqtt broker, so it could be then used in systems like Home Assistant and similar. That would require fiddling with the companion app on the phone more than with the pinetime itself.

But second part, a dedicated app/screen with maybe 2 buttons and 2 displayed values, pretty minimalistic. It should be configurable through companion app (widget type/mqtt topic), and should provide simple means to control favorite lamp at home, or for starting sprinklers when at work etc.

Not sure how we stand with free memory for additional app, but I think it wouldn't be too complex and should be doable.

[hubmartin]

Hi, thanks for bringing this up. This feature is what I wan't also to achieve with InfiniTime. I have dozens sensor/actuators in my home with MQTT, like doorbell, sensors, lights and garage control. However I also use Node-red on my server to interconnect different protocols, so I might be fine with any protocol control from my watch.

Companion app

To achieve this also companion app has to support it. Monhts ago I compiled gadgetbridge and tried to create separate simle "hello world" android app to connect and send mqtt packet. I have no experience with Android programming (Gadgetbridge) so this was just my test. On the BLE level i guess there has to be some characteristic which will be neede to invent to do one of the protocols like HTTP, MQTT or others. I googled if there is some standard like TCP over BLE but with no luck, also it will be too much complicated to put HTTP/MQTT client stack on InfiniTime. Now how the BLE communication snd protocol will work? Should companion app be set to some HTTP/MQTT broker? Or shout it behave just like a bridge and all the IP addresses and ports will be in the watch? It needs to be discussed what will be the best. (then there is the "security", should bridge also act as a firewall? should Watch FW have access to the who HTTP internet? :) )

InfiniTime firmware

I'm an embedded C programmer still struggling to understand C++ code in this project, but it is definitely easier for me than to learn Android development. So from my point of view I would like to put all the configuration and settings to the watches, and companion app will be just dump bridge with practically no UI. With all the logic in InfiniTime, there should be some user configuration, because no one likes to recompile firmware just to change IP. Now we have filesystem LittleFS which can have configurations for example for MQTT message buttons and IP address. To enable configuration I'm now also experimenting (and struggling in C++ :) ) with BLE Console, which could be used to configure watch and maybe browse and edit files in LittleFS. See #560

I can imagine that for start we can live with HTTP requests from watch.. even without reply, to control some basic actors in our home like lights, garage doors. But MQTT both ways would be definitely great goal.

It would be great if more people would gather here to see how much people would use this feature and also to find some Android developer who could help us to implement HTTP/MQTT in Gadgetbridge.

[drzacek]

I think that PineTime shouldn't handle this. Http stack, and mqtt client would take precious resources, and most likely increase power usage (and we don't exactly got weektime between charges even now). It should just send data over BLE in some simple way, so all companion apps could easily integrate it, or at least that this new payload won't break compatibility of the current apps (srsly I have no idea how Bluetooth communication works).

Anyways, offloading the mqtt (or alternatives) to the gadgetbridge seems to be the right approach IMHO.

[Avamander]

Quite certainly all (IP) networking functionality, including TCP and TLS, should be offloaded to the companion. There's no good reason to do those on the watch.

It wouldn't be difficult to: a) Implement a new service that contains a characteristic for each of your buttons b) Make the companion listen to the notifications and broadcast an intent/dbus message when detected c) Whatever you do with that info afterwards is up to you

[hubmartin]

Right, the MQTT/HTTP/whatever client has to be in companion app of course. I might not stated that clearly. Of course that over BLE will go only: Send this message to that topic. However this task is really complex from BLE service/characteristic (which I could help) to other tasks I do not understand like create new C++ classes, Gadgetbridge intent integration, another Android app (or could Tasker do that?). My knowledge is really minimal in this area so my only hope is that more people would like/use this and more skilled programmers would focus on that.

[Avamander]

Implementing the watchapp with buttons and service would be the first step anyways, if you complete that the rest can follow.

[sporkbyspork]

See #243. I don't own a PineTime, but I'm on the watchout for a Pebble replacement when the time comes. With Pebble, the "thinking" could be done by a Tasker plugin where you configure the menu and the events. Then the companion app pushes the current menu to the watch and receives the returned selection. Tasker can then react.

[Utopiah]

Also interested in bringing such functionalities to WebThingsIO but probably focusing on the companion app and limiting the on watch controls to sending few commands for the favourite Things.

[valpackett]

The watch could broadcast the desired information in advertisements (beacons), and e.g. https://github.com/shmuelzon/esp32-ble2mqtt/blob/master/main/broadcasters.c then could have support added for the beacon format.

One cool smart home feature that could be implemented is room presence detection: the watch would scan advertisements in the background and compare the list of closest ones (by RSSI) to known lists (which devices are in which room). The detected room would be broadcast into mqtt.

[Utopiah]

@unrelentingtech Interesting but both assumes that the gateway is in BT range, otherwise the phone could do the same more efficiently.

[valpackett]

Yeah, FIND3 already does this for phones, in an overcomplicated way (two server applications, one of which is doing "AI" things, instead of simple heuristics and direct connection to MQTT/etc from the phone). But the advantage of doing it on a wearable is, you won't have to always carry your phone around. And isn't that the whole point of wearables?

[drzacek]

I would agree if this would be wifi-enabled device, but it is only bluetooth. It would require dedicated bl gateway, and not even one, only multiple in house due to low range. So the functionality would be limitted, or not applicable to most users, and this feature is already not something every pinetime user would need. More mainstream would be to let companion app handle it. Afaik, the ble api/communication is there, so the gateway, like rpi, could just have some kind of companion app to handle it?

[Utopiah]

"the advantage of doing it on a wearable" again that depends on the range. I do have BT on my GW so I'm happy to test and tinker with but I'm skeptical that without a companion phone with WiFi I'd be able to go further than a room around the GW.

[Avamander]

Closing as a duplicate of https://github.com/InfiniTimeOrg/InfiniTime/issues/243

[hubmartin]

@Avamander Hi, I have some work in progress together with @drzacek. I thought that we might share our progress in this thread. I did not created PR yet since I have my python code which is separate from Infinitime repo. Let me know if you have any suggestions. This is not duplicate of 243, this is specifically focused on MQTT.

[Avamander]

@hubmartin in the end it's not the watch speaking MQTT, is it? If it's just a HA watchapp, I think the older issue would be more suitable for it.

[JF002]

Hi @hubmartin ! Sorry for the disagreement! We are trying to clean the backlog of issues and to remove duplicates entries. I'm not sure either I understand the distinction between this issue and #243. Maybe this one is more focused on lower level experimentations? Anyway, I think this is a really interesting subject and I would not want you and @drzacek to stop working on it because we are closing a few older issues so what do you think would be the best : continue the discussions on this issue? Or on #243? Or on a PR? Create a new Github project to centralize issues and PRs related to home automations?

[hubmartin]

@Avamander @JF002 I'm sorry but I confused this Issue with PR #624 where the @drzacek app and my progress will be published. So this issue could stay closed. My fault.

[JF002]

Don't worry, it's easy to be confused by the number of issues and PRs that are currently open :)