[APP][Pro] Device Capabilities - Enhance the capabilities of devices

[Niels_Veldman]

Thanks for this great app!

I have one question: when I create a new device, only use 3 numeric fields, there’s always a Yes/No capability. It’s name is Yes/No and I can’t remove it. All other Names are empty.
What do I do wrong?

[Peter_Kawa]

Hit ‘Name’ and erase text, and save.

[Niels_Veldman]

The Name at all Yes/No fields are empty. There is no capability with the name Yes/No.
When I enter one or more names, then they are added. But leaving all names empty removes all Yes/No capabilities, except the one that’s always there.

[Arie_J_Godschalk]

Which version of DeviceCapabilities are you running?

Because the current/latest version does not create an extra Yes/No, just the default one, which can be removed be clearing the name.
But if you have the version from yesterday evening, you might have the one with a bug in it which created one extra indeed.

[Niels_Veldman]

1.9.74 / auto-update on with test version.

[Arie_J_Godschalk]

fill the name of yes/no 1, press save, clear name and save again.
Best do this in my.homey.app so you can have the device-sensor tab open and see the capabilitites flip away and back. (or other way around)

[Niels_Veldman]

I did an app restart and created another new device, looks ok now.
Thanks!

[Arie_J_Godschalk]

you can still “save” the first device, so keep flows intact, by following the above given steps.
Creating yes/no again will link the yes/no back to the lost-one.

[Arie_J_Godschalk]

About how heavy HOOP is:
The app.json of hoop is 8746 lines (mostly handwriten).

DeviceCapabilities currently in develope is allready 13415 lines

For each icon included, it has 4 capabilitites each in a few variants, so there are a loooooottt of possible capabilitites.

Fortunately those possible capabilitites (is purly capability definitions) are not memory heavy in any way.

[Arie_J_Godschalk]

List of icons will be updated shortly:

[Arie_J_Godschalk]

Coming up: 10 possible Camera’s

[Joka]

@Arie_J_Godschalk

Yeah, hoop is heavy, but just as heavy as DeviceCapabilities, no more or less.
But i needed the device elevator so the app has access.
Writing another app takes quite some time, so this was the only way to fix it.

HOOP itself just uses webapi, the exact same as DeviceCapability, but with increased access (athom-cli access). It works the same way as homeyscript works, except an ElevatorDevice for increased security.

And like i sayed, no devices are needed from hoop, i put the card in the main action cards.

Good to know, no criticism, maybe my imagination about the app memory usage was not right. And thx for explanation about the elevator rights cause I asked myself why hoop can handle the device naming and devicecapabilities do not.

[Arie_J_Godschalk]

DeviceCapabilities, and other apps that use the Athom-Api, don’t really have all rights to do everything on Homey, as it is states on the permitions section on the App site.

I though HomeyScript could do that, it has higher scopes/access then any other App.
But apparently it also has not enough rights.

HOOP version 0.1, 2 years ago, accessed the HomeyScript App to create a script that returned the access code from HomeyScript, then executed that script to retrieve the code and then used that code as the elevation to HOOP. But as soon as i submitted it for Review, and Athom realized the hack used, and that there was no way for them to stop the security-breach, then they decided that Apps no longer could connect to HomeyScript.
After that, HCS with an Elevator to use the Athom-Client scopes was the only way to give HOOP enough “power”.

[Le_Cactus]

@Arie_J_Godschalk

Ready in test: 10 times all fields!

@Le_Cactus unlimited is not possible when i use Default Device Settings, the are fixed before install.
But i did create a script that writes the app.json for me, so when i add something, a setting for instance, i dont need to add it 10 * 5 * 4 times.

@Arie_J_Godschalk

Yes! I found a way:
In the next version, not yet in test, you can set Yes/No’s as a Button and then “disable” it.
This way you get it as a sensor value ( i will check if i can hide it) and not as a button.
Also you cannot click on the button.
But in the Mobile App, the Device gets dark or light based on the value of the Yes/No, which you can set through FlowCards.

No buttons, but dark when “Nee/No”.
And light when zet to true/yes.

Played around with this, and this was exactly what I ‘needed’, everything works now as expected! Great work!!!

With this I can replace some extra flow and make some virtual device even better.

[Arie_J_Godschalk]

Please note that i will change a few “small” things:

• Yes/No Show as → DropDown
• Button Show as → DropDown
• SetClass, this way you can set the class that you would like (since it sometimes makes a difference for other apps): like make it a Light device, or a mower perhaps

So as long as its Test version, there might be some small changes.

[Le_Cactus]

In the version 1.9.74 you can only set the status text if you also set a number. So the number isn’t optional anymore. Tried the normal fixes (rename status field, restart the app) but is seems it’s a program glitch. Just a heads up

[Arie_J_Godschalk]

Depends on where you want to see it?
In Mobile or WebApp?

[Le_Cactus]

Both. If you also add a number they are both (the status text and number) visible on web and mobile. I know mobile doesn’t update (alrhough changing zone, or close and reopen app does reflect the new values) but without a number the status text isn’t updated, both in mobile and web. It is set to just a dash (-)

[Arie_J_Godschalk]

Yeah allready thought it would be an issue: how do i know if you want to clear the number or just wanna leave it empty so it remains the same as it allready is…

Just created an extra flowcard to only set the text.
So if you take the numbercard, it is ment to Clear the number.

[Le_Cactus]

Supurb!