search

icanos / hassio-plejd

Hass.io add-on for Plejd home automation devices
Apache License 2.0
126 stars 36 forks source link

Virtual device #185

Open vBrolin opened 3 years ago

vBrolin commented 3 years ago

Found this pdf. It's in Swedish but I guess that's probably Ok here. https://odr.chalmers.se/bitstream/20.500.12380/301953/1/20-22%20Ericsson.pdf If I'm not reading this totaly wrong, he seems to be able to create virtual devices that integreates to the Plejd system.

If that's possible, it would be really useful to be able to either create a virtual device to use for Scenarios you wanna pick up in HA, but shouldn't do anything in the Plejd system. Right now you have to sacrifice a device for that. For example, I got a scenario that triggers my car to start via HA, right now that sets a unused CTR-01 to off, just because it has to be set to something.

An alternative path to go would be to expose actual switches, like my car engine in the example above, as a virtual CTR-01, so that I can add that to a scenario directly in the Plejd app.

faanskit commented 3 years ago

Found this pdf. It's in Swedish but I guess that's probably Ok here. https://odr.chalmers.se/bitstream/20.500.12380/301953/1/20-22%20Ericsson.pdf If I'm not reading this totaly wrong, he seems to be able to create virtual devices that integreates to the Plejd system.

If that's possible, it would be really useful to be able to either create a virtual device to use for Scenarios you wanna pick up in HA, but shouldn't do anything in the Plejd system. Right now you have to sacrifice a device for that. For example, I got a scenario that triggers my car to start via HA, right now that sets a unused CTR-01 to off, just because it has to be set to something.

An alternative path to go would be to expose actual switches, like my car engine in the example above, as a virtual CTR-01, so that I can add that to a scenario directly in the Plejd app.

This is IMO interesting. To get your use case understood, I have rephrased it as a user story:

User Story 1

As a Plejd App User I want selected Home Assistant devices (such as my car heater) to be present in the Plejd App as if they were Plejd devices so that I am able to control my Home Assistant devices using the Plejd App

User Story 2

As a Plejd Physical Input Device User I want selected Home Assistant devices (such as my car heater) to be present in the Plejd App, as if they were Plejd devices so that I am able to control my Home Assistant devices using the Plejd App

For US1 the approach with virtual devices is interesting. Likely a lot of work to make it happen. For US2, this can partly be done with WPH-01 (with some more more code, see #172). To to the same with any button on any Plejd device is maybe not even possible due to how the BLE mesh is implemented. To go all the way, virtual devices is interresting.

vBrolin commented 3 years ago

As you say, most of this could be accomplished if we could get all inputs into HA, but yeah, there are still interesting scenarios where virtual devices would have it's uses, or just simplify automations, like if you wanna add a single Hue light to multiple Plejd scenarios.

faanskit commented 3 years ago

Ok, now I read the report. Use-case and implementation is completely different.

The report plejd_sim As you can see in this picture, the simulator injects software into the app that communicates with a device server over websockets. This is not an option for us. We would have to emulate a Plejd unit, from installation to removal. Quite a task

What we would need plejd_sim_2 This picture illustrates what would have to do to create a simulator. It can be done, but a lot of reverse engineering of the protocols between App and Plejd as well as deeper knowledge of the BLE communication and how Plejd devices are added to a system. I think Plejd would not want this to be done, therefore a volatile proposition. Even though interesting, I do not think it will happen.

In interesting find plejd

Version "always" set to 01 Don't respond flag = 10

vBrolin commented 3 years ago

Thanks for analyzing the whole paper. I trust your evaluation, and hopefully there is at least something to pick up from it.

SweVictor commented 3 years ago

I second that the approach in the paper (though interesting) does not seem reasonable for anyone outside Plejd to create (requires internal fiddling with the Plejd app if I understand it correctly).

I have, however, been thinking about another option: Registering ONE virtual BLE output to the Plejd mesh and set specific inputs to "control" that output thereby forcing BLE updates for RTR-01 devices for example.

I think that as well would be A LOT of work, but at least it would be possible.

Thoughts?

faanskit commented 3 years ago

Thoughts?

Intriguing, and likely doable. A bit easier than the complete simulation assuming you do not intend to push updates back to Plejd servers.

The trick will be to choose a BLE address that is not (an will not be used by Plejd. With some luck it not that hard. In theory it should be as easy as sniffing the BLE when you configure the RTR to a different output than the host it is attached to; then replicate with your "fake" BLE address.

I have a wilder thought than that. And the task huge. The problem with Plejd is that it is closed source and depends on Plejd back-office servers. Plejd has a business model depending on expansion, incurring more and more cost to run the servers. When expansion stops, they will likely implement a paywall. I hate paywalls.

Two approaches: 1 - Different firmware The devices are quite standard. Within sits a National Semiconductor CPU that can run Arduino software; which has a BLE stack. So, whip up a new firmware and talk MQTT directly to/from the device.

2 - Replacing the servers If (1) fails, it should be possible to replace the need to Plejd servers totally. But the level of hacking / reverse-engineering the protocol is equal to the original post. But, it looks like Plejd is using off-the-shelf cryptography - so it is doable.

faanskit commented 3 years ago

Btw, it's this baby that powers the Plejd devices. One could likely start from RBL's units, like this one.

SweVictor commented 3 years ago

1 - Different firmware The devices are quite standard. Within sits a National Semiconductor CPU that can run Arduino software; which has a BLE stack. So, whip up a new firmware and talk MQTT directly to/from the device.

That IS a wild idea 😄

To me, the whole reason for using the Plejd eco-system is the rock solid super-fast performance, so to me rewriting the firmware is not reasonable.

Regarding 2 (replace the servers) it's not really needed I think. The Plejd system works fully offline, BLE-config only.

So - if you ever get this addon up and running (with the current version) it will cache the API response and after that be able to run fine fully offline.

... which of course also means you could rewrite this addon slightly if paywall happens to use BLE data only (instead of API)

... which is basically what https://github.com/klali/ha-plejd does already, so you could also switch to that 😉

faanskit commented 3 years ago

Regarding 2 (replace the servers) it's not really needed I think. The Plejd system works fully offline, BLE-config only.

Yes and no. It runs offline for a steady state system, but good luck adding a new device. Also klali's implementation depends on Plejds back-office servers to bind the different plugs and switches together via the App.

That is my problem. Having my home fully dependent on a public company with closed source as part of their strategy. So even if Plejd is not evil today (no charge for the app), there is nothing that forces them to be that in the future. When I purchase the plugs, there is no contract from Plejd towards me that guarantee that they will work in the future.

Had they implemented all the logic in the app, I would know that I could revert back to old versions. Now we are totally dependent on Plejds servers to be functional (and free of charge) for our systems to evolve.

If Plejds expansion to EU fails; being a listed company they will have to keep the revenues coming. Today they depend fully on expansions to new markets. What if the markets are not interested. There is only one remedy. Paywall.

At this point, I think the paywall is +3-4 years away. Even though this mild flaw in their business model, I think they will prevail. Their strategy is intact. Butter up the wholesalers, build high-quality products and make the work easier for the electrician and it sells itself.

Information wants to be free, so therefore we need to reverse engineer the full BLE protocol at some time....

klali commented 3 years ago

Jumping in a bit.. replacing everything the app does shouldn't be very hard, mostly that my interest stopped when I could control enough without the app, I can live with using it for setup as long as it works. For me it's an objective that my home solutions are not dependant on cloud services controlled by someone else for day-to-day tasks.

A bit more challenging (but probably not terrible either) would be to write some software that could pretend to be a product in the mesh instead and show up in the app if you so want. The main reason (I think) for doing something like this would be the ability to maybe capture more data from the mesh than what we've found out to be available today.

It's probably not terrible to write new firmware for the plejd devices, but if you're interested in that you'd run something else than Plejd I think. From a reversing perspective it might be interesting to dump the firmware from a device, but I don't have the inclination to spend that time without a clearer goal.