Yeah, I thought so. That’s too tight. You need to clear some space on your root partition. The usual suspects are plugin files remaining for plugins you’ve uninstalled, old firmware files, energy data and alerts.
I’d start by examining /etc/cmh-ludl for files for plugins you’ve uninstalled. This can be a pretty delicate operation; if you’re at all uncertain, I’d contact Support and ask for their help. But the idea is that if you’ve uninstalled “XYZPlugin”, you should be able to safely rm the D_, I_, J_,L_, etc. files it owns, or, if you’re very careful, you can rm *XYZPlugin*, but be careful… just a space character in the wrong place and it will start erasing the entire contents of the directory. Again, if you’re at all uneasy, Support will get you through this quick.
Perfect. Got it up to 1.6M of free space in /etc/cmh-ludl. Hopefully that will be good enough. I’ll take a look at picking up an ssd to extroot as well.
Is there any hope that tri-state switch will ever be supported in the vera android app?
Tri-state switch are great however, if we cannot select them via the App it’s a bit disapointing. If we start relying on them, it needs to be supported.
It is a long-standing limitation of the mobile apps that they do not support the user interfaces provided by most plugins (there are a few rare exceptions Vera has hard-coded). Everything Vera needs to provide a UI is there. The fact that they can show the correct icon for the device state even means that they have read that data and are using at least that fraction of it. Maybe someday they’ll go the last mile. As of now, there’s been no indication this will change.
Thanks for the update. I was kind of expecting something like that. It is strange that all is working fine on the iOS APP. I am wondering if it is not simply a bug in the android app rather than a decision not to support it. That being said, having both iOS and android devices, it is not the first time that I notice things now working as well on the android side. There is clearly a difference.
This has nothing to do with this thread but when we look from a distance, the way both Apps are developped, seemed rather odd. It is as if two different teams are implementing changes without talking to each other. I understand that each OS has its own limitation but honestly, there is room for improvement when it comes to way things behave and are displayed. From what I am seeing with the new Dashboard, things are not improving with respect of having both app at par. I will start reporting discrepecies/shortcoming on the proper threads.
Hello. I want to control your switch via “Node red” in “Home kit”. I can get the status of the switch in the “Home kit”, but I can’t control the switch through the"Home kit". “Home kit” sends via “Node red” (SetTarget-1) but the switch does not respond.
If your overarching goal is to use HomeKit with Vera, I recommend that you checkout homebridge-vera. That will eliminate the mqtt element of your current solution because it bridges HomeKit to the Vera via http.
If you really want to continue down the mqtt path, make sure you have the version of the mqtt client that can receive messages in addition to sending (there is a fork somewhere).
The SetTarget action in the urn:upnp-org:serviceId:SwitchPower1 service is supported (otherwise the device’s own dashboard card would not work). You might check your LuaUPnP log file to see what is logged there. I don’t use NodeRed or Home Kit so I can’t be of much help there, but these virtual switches implement all of the standard behaviors and actions.
Cool. Are you using one of the forks that extended the mqtt-client with subscription capability? I believe @vosmont added it here - Commits · vosmont/vera-mqtt · GitHub Not sure why the various forkers haven’t submitted pull requests to the original repo so there is a single source but it is what it is so you might want to inspect the various forks to see if there are other changes that apply to your use case.
@sagos, I guess I don’t fully understand your setup but if the conversion functions run in node-red which in turns sends an mqtt message to your Vera, then you need the version of the Vera mqtt client that can “receive” the node-red messages - the original Vera mqtt client can only publish messages, not receive messages.
Hi! I have a huge number of legacy virtual switches set up. Is there a way to migrate them to switchboard switches en masse without recreating them and their associated scenes one by one? Appreciate any advice I can get, thank you.
I’ve only recently discovered as part of the Sonos project that there’s a way I can “adopt” a device and make it a child that seems to work. Switchboard does not yet have this capability, but if you want to wait a day or so, and you happen to have a thick skin and an unhealthy taste for risky experiments, I can add it to the current development version and you can try it out. I’m not kidding. Are you game? If it works, it would be an undeniably huge benefit.
Edit: Well… there’s good news and there’s bad news. The good news, adopting the existing devices works, no problem. The bad news, unfortunately (and obviously, now that it’s staring me in the face), is that when they change from the VSwitch device type to the Vera-standard device type, the old VSwitch1 service goes away. This means that if you have code that uses the VSwitch1 SetTarget action instead of the SwitchPower1 SetTarget action, that code will not be able to manipulate the switch. The old VSwitch plugin should never have implemented its own version of SetTarget–it was unnecessary, given that it could have simply used the standard SwitchPower1 action of the same name. But it did, and I suspect a lot of people have ended up using it, rather than using the standard one.
So, while I can adopt the switches and preserve the device numbers and have them inherit the benefits of Switchboard virtual switches, I cannot replace or continue the old service actions, and that’s going to send you running to fix all your code/scenes anyway–you’ll need to modify them to use the standard service ID urn:upnp-org:serviceId:SwitchPower1 (otherwise it’s the same, though).
The stable branch on Github has been updated with the adoption code, in any case. It’s still a step in the right direction, even if the upgrade isn’t completely seamless/effortless, so I’ll leave it. There’s now an “Adopt” button under the list of switches in the Switchboard control panel.