Custom Plugins

[profiluefter]

Hi, I think it would be a nice feature if one could create custom devices. So one could specify the device type and traits in the configuration and the values and events are then exposed in ioBroker. For example, I have a device that I control via HTTP requests and I've written a script so that it can be controlled in ioBroker. Now I don't want to write a whole plugin specifically for that device that no one else has integrated the way I have but instead I could write a script (maybe even with blockly) that executes code when a Google action is triggered and after it did or didn't successfully execute it pushes the state back to Google. I'll look into implementing this myself but since I'm not very familiar with ioBroker development yet you might be faster. Thanks for creating this adapter!

[raintonr]

The idea of this adapter is that once installed the user doesn't have to go through and map ioBroker states to Google Home devices as that is so tedious.

However, guess I can see your use case so how do you best envisage it working? Any state under 0_userdata that have specific state roles (such as switch) get created as the appropriate Google Home device?

TBH, I think doing this for role switch and nothing else would be pretty easy and should do what you need - would that work for you?

You have mentioned traits, which are Google concepts. Other than a switch, what would you need?

You have also mentioned feedback to Google but I don't see that as necessary. Once Google Home turns on a switch (or maybe pushes a button) in ioBroker it's job is done. If ioBroker then has an error due to any follow up action not really the fault of Google Home is it? Does Google Home even have some kind of mechanism for flagging errors in one's smart devices (I don't think so)?

FYI - I use Telegram to send error messages out when things go wrong in our ioBroker system.

[profiluefter]

Honestly for my use case something like HomeAutio.Mqtt.GoogleHome and the MQTT adapter would probably be the best solution. I just remembered that I've used that project before and I don't have to use an ioBroker-specific solution for everything.

Any state under 0_userdata that have specific state roles (such as switch) get created as the appropriate Google Home device?

Definitely sounds like a useful feature to me. The way I imagined it would be that after configuring what devices (and traits etc) should exist it would create the states for them in google-smart-home-fulfillment/device-name. I don't know the conventions for ioBroker on what's the correct approach.

TBH, I think doing this for role switch and nothing else would be pretty easy and should do what you need - would that work for you? You have mentioned traits, which are Google concepts. Other than a switch, what would you need?

For example, I have a radio which only has a local API (frontier silicon; an adapter exists but doesn't have a plugin and creating a plugin for everything is too much work IMO) so I would use the speaker type with volume trait etc. This way I can say "louder" and Google knows I mean the radio when it's playing or the Google Home itself when the radio is not playing. Using a switch I could achieve the same possibilities but I can't use "native" commands. (You can't make a routine which triggers for "louder" afaik; also it can't guess the device then) Also I would have to enter each variation of a command into the routine and I would rather let Google figure that out.

You have also mentioned feedback to Google but I don't see that as necessary. Once Google Home turns on a switch (or maybe pushes a button) in ioBroker it's job is done. If ioBroker then has an error due to any follow up action not really the fault of Google Home is it? Does Google Home even have some kind of mechanism for flagging errors in one's smart devices (I don't think so)?

Sorry, I described that a bit weirdly. I meant reporting when a state changes regardless if it was due to a voice command. E.g. when I turn off a device using the button on the device I want the device to be turned off in the Google Home app. I use the app kind of like a not very customizable visualisation.

FYI - I use Telegram to send error messages out when things go wrong in our ioBroker system.

I've used Telegram before with Home Assistant. Didn't know there's an ioBroker adapter, thanks!

---

So tl;dr: I think this would be a nice feature but it's actually already solved by the HomeAutio project. You can reopen this issue if you want to implement it regardless. Thanks for your time!

[raintonr]

https://github.com/i8beef/HomeAutio.Mqtt.GoogleHome does look interesting, but am not sure how easy that process is going to be.

The way I imagined it would be that after configuring what devices (and traits etc) should exist it would create the states for them in google-smart-home-fulfillment/device-name.

Ah... no. You have this the wrong way round. This adapter doesn't create states/devices/etc as that wouldn't make sense. It needs an existing device to control (turn on/off, etc).

Example is that we have a Loxone system (which I primarily created this adapter for) and the ioBroker Loxone adapter creates states in ioBroker for lights, shutters, etc. As those states already exist under the Loxone adapter object tree this fulfilment adapter 'knows' (it's in the code) what to present them to Google Home as.

In your example of a radio with a local API but no adapter. I'm not sure what you mean by 'local API' but assume you mean you can just sent regular REST requests to it to change volume, etc?

Say the volume level can be 0-100 - you need a state in ioBroker to represent that. Normally this would be done by the adapter that communicates with the radio, but there isn't one. So you need to manually create a state under the userdata object tree for this. You could then create a small script in ioBroker Javascript module which use the on state change to detect... erm... changes in that state and send the correct REST request to your radio to set it's volume to whatever the ioBroker state was changed to.

That is just regular ioBroker stuff - you would now have a way to set the state using any means you like within ioBroker and have the radio's actual volume change based on that. Side note: if someone changes the volume on the radio manually then the ioBroker state will now not be in sync so the 'local API' should have feedback using polling, etc. to prevent that.

Anyhow - so once working, say the radio volume state has a level.volume role. I could add a 'generic' plugin to this fulfilment adapter that presents any state with a level.volume role to Google Home as volume trait and... voila!

Sorry - bit long - but that is what you mean, right?

[profiluefter]

Yes that's what I mean and I already implemented polling. This sounds perfect but how would I, for example, also attach an OnOff trait and an MediaState trait to the same device? Create a parent state that has the device name and the children are the traits? I haven't really looked into ioBroker state roles and similar so I'm not sure how they work. (Also it would be nice to specify the device as the correct type, although this only changes the image in the app afaik so it's not a priority)

[raintonr]

If I were to build something 'generic' it wouldn't care about trees or anything. It would just map roles in ioBroker to traits in Google Home. Edit: I would make it just use the object name, role (for trait mapping) and room. If you wanted to have a radio device with both on/off and volume traits... erm... I guess you could just use two states with the same name but different object IDs and roles for each trait and that would work?

So you already did the userdata tree for your 'local API'? I think it would be very easy to do the role -> trait thing I mention and work better than an MQTT intermediary.