Best Structure for new Binding (Wolf Smartset)

Development
1

Hi,

currently I’m trying to find the best structure for a binding to integrate the Wolf Smartset portal.

The cloud-portal structure is like this:

  • Login (Username Password) for wolf-smartset.com
    • List of Systems (each connected via internet with a Bridge-Device). Can be a single Heater or a combined device of heater, solar, etc.
      • foreach system multiple sub-systems in my case i have a heating device CSZ containing parts like: “Bedienmodul BM0 Einstellung und Anzeigen”, “Bedienmodul BM0 Parameter”, “Heizgeraet”, “Heizgeraet ParameterHG”, “ISM”, “Parameter SM1”, “Solarmodul SM1”

each sub-system hast multiple values (approx. 10 - 50)
I could create a thing for each “sub system” and create a bridge thing for the system holding all sub-systems together.

Or create a thing for the system with all values in a single channel.

Currently i have started with the miio binding and copied some code for the cloud connection and the discovery. There is the username & password ist stored for the binding and not for a thing. I don’t know if this is the correct way.

2

Typically, the bridge Thing represents the connection to the cloud API. Then under that you’d have the Things that represent the devices. I don’t think it’s possible to have nested bridge Things so I think that ends up answering your question. You probably can’t have a Bridge Thing that represents the heater with sub-Things to represent the subsystems because you need the Bridge Thing to be that connection to their cloud API.

Beyond that the answer depends on whether the there are any Channels that would be just on the parent Heater, or if all the Channels would be part of the subsystems. If the former, I’d make one Thing for the Heater and all the Channels for the subsystems would go under there. If the latter, I’d not represent the Heater itself with a Thing and create a separate Thing for each of the subsystems.

3

Not sure if this matches what you’re looking for, but the Ecobee binding has

  • an account bridge for the ecobee account, which handles all comms with the Ecobee cloud API
  • thermostat bridges that reference the account bridge
  • sensor things that reference the thermostat bridges
1 Like
4

So you can have sub-bridges. I didn’t think that was possible.

5

You may also want to take a look at the sensorpush binding that I recently created a PR for, not so much because the code is great as because it is relatively simple and easy to follow. There is a bridge thing that connects to a cloud service using a REST API, and simple sensor things that hang off of it. An associated discovery service is implemented as a ThingHandlerService.

6

If it is unlikely that a user / system has multiple API accounts, you can set account data at binding level.
On the other hand it is perfectly possible to nest multiple bridges levels.

1 Like
7

Thanks, the Ecobee-binding seems to be the best starting point.

8

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.