Skip to content

Vera

Discuss your vera problems and findings here

58 Topics 858 Posts
  • How to reset a Tripped state?

    3
    0 Votes
    3 Posts
    260 Views
    toggledbitsT

    If you're doing it from MSR, use the x_vera_device.set_variable action on the device to set Tripped (service Id urn:micasaverde-com:serviceId:SecuritySensor1 to 0.

    An HTTP would do essentially the same as the above ('http://vera-ip:3480/data_request?id=variableset&DeviceNum=NNN&serviceId=urn:micasaverde-com:serviceId:SecuritySensor1&Variable=Tripped&Value=0`).

    And of course, you can do it in Lua: luup.variable_set( "urn:micasverde-com:serviceId:SecuritySensor1", "Tripped", 0, device_number )

    Devices in the SecuritySensor1 service also support an AutoUntrip state variable that if set to a non-zero number of seconds will reset the Vera device (not the physical device) to untripped after that time. If you have to create the variable, the service ID is the same as that listed above.

    Keep in mind that any of these manipulations of the state variable have nothing to do with what the physical device thinks, so Vera won't report the actual reset of the device (because Tripped has already been set to 0/false), and any refresh of the device (e.g. Luup reload) may cause a retrigger.

  • OpenSprinkler devices (valves) not showing up in Vera

    3
    0 Votes
    3 Posts
    268 Views
    therealdbT

    @futanare I've not really updated the App Store versions of my plug-ins in the latest months, partly because the dev portal is frequently offline/with errors, partly because I've lost faith in Vera as a platform. download it from GitHub and give it a go. If I find time, I'll update it on App Store as well.

    EDIT: also, set DebugMode variable to 1 and post some logs. Vera FW version and OpenSprinkler FW version are also appreciated.

  • Ezlo Plus as Network Attached Zigee & Z-Wave Device

    10
    1 Votes
    10 Posts
    1k Views
    J

    The Zooz stick and the Ezlo share a common Z-Wave chipset. In fact when I added the Ezlo to ZWave-JS it shows up with a product code of ZST10-700, which I believe is the Zooz stick.

    So, good news! I have both Z-Wave and Zigbee working in home assistant now, bypassing all the Ezlo software. The home assistant Zigbee integration connects directly to the Ezlo, and for Z-Wave I have ZWave-JS as an intermediary - but that's hass' recommended configuration anyway.

    I think I've figured out some initial stability issues I was having as a result of not setting socat up quite right, but don't quote me on that yet, and for some reason the status of the Z-Wave controller shows up as 'Dead' but it doesn't seem to matter? Not sure what that's about. Also if I start hass before the Ezlo is ready then it will never successfully connect - you have to run socat on the Ezlo first, then start Home Assistant. Other than that it seems to work well. Zigbee in particular is more stable and responsive in this configuration than it was on the sonoff zigbee bridge I was previously using in my setup.

    Here's how I did all this:

    Using the instructions on the openWrt site, compile socat for the Allwinner H3 SoC (or, if you're feeling trusting, download the binary I already compiled). Copy the .ipk to the Ezlo using whatever method you prefer. I used scp. Unfortunately you can't download the binary directly to the Ezlo because it doesn't support SSL and I don't have anywhere I can share the file from that doesn't enforce secure connections. Install it:
    opkg install socat_1.7.3.3-1_arm_cortex-a7_neon-vfpv4.ipk Kill the running ezlo processes: (One single error at the end about a process that can't be killed because it doesn't exist is expected).
    ps | grep "/ha-" | cut -b1-5 | xargs -t kill Share the Z-Wave and Zigbee radios over the network using socat:
    socat /dev/ttyS1,raw,echo=0 tcp-listen:3333,reuseaddr,keepalive,fork &
    socat /dev/ttyS2,raw,echo=0 tcp-listen:3300,reuseaddr,keepalive,fork & In Z-Wave JS' ZWave settings under serial port, ignore the choices in the dropdown menu and manually enter tcp://192.168.0.100:3333 (change the IP to that of your Ezlo) In Home Assistant's Zigbee integration select a radio type of EZSP and for the serial port enter socket://192.168.0.100:3300 ... Profit

    If you reboot the Ezlo it returns to its stock setup. I think my plan is to write a little script that checks whether the Ezlo processes are running and, if so, kills them and starts socat, then run that script as a cronjob. @rafale77, do you have any advice on a better approach based on your Nuke-Vera work? I don't want to nuke the Ezlo and do anything irreversible necessarily, but I'm also a little concerned that my plan might be leaving the thing functional enough to one day download a firmware update that breaks what I'm doing.

    If it's helpful to anyone, I also compiled binaries for ser2net (I never got it to work) and Nano.

  • Messaging after VERA decoupling

    19
    0 Votes
    19 Posts
    740 Views
    S

    I use homeassistant with node red and telegram natively. Alternatively I use the homeassistant companion app with messaging. Both rock solidand instant.

  • Backup

    3
    0 Votes
    3 Posts
    231 Views
    T

    @rafale77 - I'm so sorry for my delayed response. I didn't get the alert in my inbox (or blew past it).

    I will look in to this. I have previously read your migration instructions but, the last I checked, the security key part was omitted. I'm still willing to wait out Vera/Ezlo but I'm nervous that I can't get a replacement controller. If this thing dies, I need another move.

    I'll revert back with questions but I remember the guide being very well thought out. Glad to see this community coming together over here.

    Thanks gain.

  • Deleting Multiple Devices without Reload Inbetween

    5
    0 Votes
    5 Posts
    318 Views
    toggledbitsT

    @pabla said in Deleting Multiple Devices without Reload Inbetween:

    now I am playing the guessing game for when its done lol

    You got it figured out, but the benefit of future readers: just wait for the reloads to stop. If it goes longer than two minutes without a reload, it's done.

  • Deleting Child Devices without Deleting Parent

    1
    0 Votes
    1 Posts
    112 Views
    No one has replied
  • Vera Alexa Plugin 7.32

    119
    0 Votes
    119 Posts
    9k Views
    LibraSunL

    @catmanv2 said in Vera Alexa Plugin 7.32:

    It would be quicker to ditch it and go OpenLuup. Just saying 😉

    C

    Undoubtedly. I've got OpenLuup installed (but not currently running) as a Docker container, for future exploration.

    Meanwhile, I went ahead and re-downloaded Vera Alexa from Github, installed it (seems to be version 0.94 instead of 0.92), did a million restarts to get the new device recognized, configured, and stable. Seemed to really lag on some of those steps, but can confirm full configuration achieved, 'Alexa' folder present, cookie and all.

    Next, on to testing... as expected, in rev. 0.94 (using the v0.17c .sh file), every say or command attempt results in silence but no errors**, while the routine action works perfectly. Exactly the opposite of rev. 0.92 (using the 0.17a .sh file).

    **Here's a typical log entry in Debug mode:

    08 04/16/21 11:42:50.143 JobHandler_LuaUPnP::HandleActionRequest device: 0 service: urn:micasaverde-com:serviceId:HomeAutomationGateway1 action: RunLua <0x723cc520> 08 04/16/21 11:42:50.144 JobHandler_LuaUPnP::HandleActionRequest argument Code=luup.call_action("urn:bochicchio-com:serviceId:VeraAlexa1","RunCommand",{Command="-e weather -d 'Living Room'"}, 366) <0x723cc520> 08 04/16/21 11:42:50.144 JobHandler_LuaUPnP::HandleActionRequest argument DeviceNum=0 <0x723cc520> 08 04/16/21 11:42:50.144 JobHandler_LuaUPnP::HandleActionRequest argument serviceId=urn:micasaverde-com:serviceId:HomeAutomationGateway1 <0x723cc520> 08 04/16/21 11:42:50.144 JobHandler_LuaUPnP::HandleActionRequest argument action=RunLua <0x723cc520> 08 04/16/21 11:42:50.144 JobHandler_LuaUPnP::HandleActionRequest argument _r=1618591370147 <0x723cc520> 08 04/16/21 11:42:50.145 JobHandler_LuaUPnP::HandleActionRequest device: 366 service: urn:bochicchio-com:serviceId:VeraAlexa1 action: RunCommand <0x723cc520> 08 04/16/21 11:42:50.145 JobHandler_LuaUPnP::HandleActionRequest argument Command=-e weather -d 'Living Room' <0x723cc520> 50 04/16/21 11:42:50.147 luup_log:366: VeraAlexa[0.94@366](setVar@127):setVar("urn:bochicchio-com:serviceId:VeraAlexa1","OneTimePassCode","",366) old value "" <0x723cc520> 50 04/16/21 11:42:50.148 luup_log:366: VeraAlexa[0.94@366](runCommand@360):Executing command [runCommand]: "-e weather -d 'Living Room'" <0x723cc520>

    OK, I go shoot myself now.

  • How to throttle or stop plug-in from cluttering LuaPnP Log?

    7
    0 Votes
    7 Posts
    273 Views
    PablaP

    I have also been seeing a lot of red in my Vera logs notably the dumping XX locks

  • Instant regret after clicking "Configure Node Right Now" on device

    15
    0 Votes
    15 Posts
    589 Views
    rafale77R

    @crille

    @crille said in Instant regret after clicking "Configure Node Right Now" on device:

    Without openLuup and the excellent Ezlo Bridge, my Ezlo Plus would just annoy me and make me want to go somewhere else, as they kind of hinted with the ban raid.
    Big thanks to @mrFarmer ! for making use of the very beta product they shipped.

    Indeed, The capability to support all the wireless stacks and offering an API to control the stack should have been a day 0 pre-release requirement. I am glad they got there and kind of wished they stuck with the vera API to ease the transition but certainly @mrFarmer 's work made up for it.

    @librasun said in Instant regret after clicking "Configure Node Right Now" on device:

    While I greatly admire the "roll your own" set, I've promised my significant other that -- if I die -- everything Vera and Alexa do to run our home will be maintainable by a normal mortal. Hence my clinging to stock setups, with minimal round trips through IFTTT (gone from the mix now), Stringify (dead), Google Scripts, etc. Would not even touch PLEG due to this philosophy!

    This is the philosophy that most people who migrated away to hubitat have had in mind. Prioritizing ease of management over capability and flexibility and even then, some learning curve is required. Just keep in mind though that any cloud dependency will defeat that in a whiff. Anytime you will have a cloud dependent integration (IFTTT, google, ecobee, alexa) you are exposing yourself to the life and decision of that company. Any time they change something on their cloud or if they go bankrupt or get bought, you will need a great amount of expertise to make the changes/maintenance if that is even possible. I took this goal to an extreme where I am no longer afraid of going through very complex setup so long as it works without maintenance. The only way to do this is to make everything run independent from the cloud. The only maintenance which would be required on my setup would be to change batteries... Everything else just self starts and syncs up without anything ever being exposed to cloud server disruptions, changes or quirks all within a single machine: My QNAP NAS. Near 0 maintenance required...

    None of my cameras are connected to the cloud, no image processing, no voice commands recording, No TTS commands... Absolutely nothing. All is processed within the house and all the data remains here in one machine which turns on with the push of a button. And indeed, everything runs a lot faster too.

    So it is a trade off of short term ease of setup and maintenance (maybe) with lower level of capability vs. much more capable setup with a larger amount of setup work upfront resulting in nearly no maintenance... I understand the experience with the vera though which can be traumatizing and leading to the thought that complex implementation leads to complex maintenance. This doesn't have to be true. In most cases, it is actually the opposite. It is only true when they break all the time... vera style.

  • Deleting unused GeoFencing waypoints from Vera (Mobile)

    4
    0 Votes
    4 Posts
    186 Views
    toggledbitsT

    BTW, I have them, too, of course, from my own little soire into the world of their geofencing. I suspect they simply have no way to clean up that data short of editing user_data.json, and that will only work if the data isn't mirrored in their cloud and being synced with it. I haven't bothered to experiment with that, and I probably won't. Maybe I'll just add a flag to VeraController that you can set if you don't use their geofencing and call it good.

  • Unexplained "LinuxTest" admin account on my Vera?!?

    5
    0 Votes
    5 Posts
    190 Views
    LibraSunL

    Ah, then that likely explains it, since I do have a beta-testing Ezlo Plus, and I did authorize them to create an admin account on it recently.

    MYSTERY SOLVED! (I may leave this thread intact in case others have the same question.)

  • Second Z-wave netwerk or slave controler

    16
    0 Votes
    16 Posts
    751 Views
    rafale77R

    It would have to have a firmware to do that so as to act as a routing node. Given the nature of the device... not sure if it is possible. You already know what I did with mine...

  • Can't Purge Associations

    4
    0 Votes
    4 Posts
    338 Views
    rafale77R

    I thought that it would. Good to know that you got it fixed for now.

  • Setting Device Parameters (from documentation)

    12
    0 Votes
    12 Posts
    431 Views
    PablaP

    @toggledbits That seems to have fixed it!!

    Is there a similar way to fix the purging associations error. One device had an association that I deleted but its not configuring past "Setting Association"

  • Old VERA 1 up and running!

    3
    0 Votes
    3 Posts
    147 Views
    Black CatB

    Problem you may have is that GEN5 (Z-wave Plus) devices won't work.
    I still have a Vera Lite fully operational, it's never missed a beat since commissioning and even got the Vera tech's to upgrade the security keys on it early this year,

  • Sensative Strip showing two instances in Vera.

    8
    0 Votes
    8 Posts
    240 Views
    rafale77R

    It is a sign that the device record is in the vera's zwave chip and not only in the vera user-data file. Sorry it's been a while now since I've dealt with a vera UI but I thought there was a way to irreversibly delete a device. Maybe from the advanced/zwave menu?

  • Vera account suspended for a 1000 years

    Locked
    101
    2 Votes
    101 Posts
    8k Views
    akbooerA

    Well, this probably won't be the last time that someone from there joins us here, but, for the time being, I think it's time to move on.

    We have a critical mass of really constructive contributors here, and we should certainly be doing what @toggledbits suggests:

    "a place where technical discussion can lead over corporate policy " "take a wide view of the HA market, and not be beholden to one product" "We get work done. We get work done for each other."

    "Make it so!"

  • How to get out of plugin download loop on a vera

    8
    0 Votes
    8 Posts
    266 Views
    akbooerA

    Yes, the problem is usually getting rid of old Zwave devices once they’ve joined the network. If you do your copy, and see what you have on ZWay, it should be clear what you’ve got.

  • (Need Help) Migrate off Vera

    8
    0 Votes
    8 Posts
    455 Views
    rafale77R

    Sorry for not being of much more help. I know how painful it is to start from scratch and it is exactly what I was trying to avoid. It is also a big benefit of z-wave vs other protocols had it not been because of vera's broken implementation. It is just that I can't really get into how to recover your vera and it is likely a lot more work than to start fresh.

    When/if you get more into the automation part, you will start running into pretty steep learning curves with HA too which is why I vastly prefer doing it on openLuup and others with HA use node-red. @toggledbits is also working on an alternative: Super reactor. The one ring to rule them all. Which I forgot to mention in my previous post.

    PS: I tend to recommend against using the aeotec stick because of its specificities. It has no firmware upgrade path so you are stuck on an old SDK version. They released a new stick with a new SDK but the firmware is not upgradable. I have one and it's been a brick. Reminds me that I should probably get rid of it.

Recent Topics