I have a bit of code I wrote that you may want/use about pyvera

[kdschlosser]

and one other thing. the same mechanism that is used to build the filenames can be used if a dynamic import system is made so the file_names are generated from part of the service type. as are the class names.
the function parse_string is what does this.

This will work if the Vera is on the local network. and it is auto discovering.

[kdschlosser]

I updated the script changed how the service id's were processed. I found it was missing some things.

also gave it more informative output

vera_build.zip

[pavoni]

@kdschlosser Thanks for this, looks very interesting. I've only had a very quick look - but couldn't work out how to run it.

Traceback (most recent call last):
  File "vera_build.py", line 761, in <module>
    main()
  File "vera_build.py", line 721, in main
    ip_address, location = discover()
  File "vera_build.py", line 226, in discover
    sock.sendto(SSDP_REQUEST, (dest, SSDP_PORT))
socket.error: [Errno 65] No route to host

Assume I need to update an address somewhere...

[kdschlosser]

hmmm.... that is an odd error. I can't ever say that i have seen that from the socket lib before.

this script should automatically discover the Vera's IP address for you.

Here is a much newer version. I have cleaned up the code a lost but I have also found some back doors in the Vera. I am not able to grab a list of all of the device and service files and able to grab them from the Vera so they can be parsed.

I have added properties for the attributes that are deemed to be changeable by the user and not the program. I have also change the structure of how the classes are made. I found that the vera just like in python uses a class subclass style. as an example

class BinaryLight1(SwitchPower1, HADevice1, ZWaveDevice1)

BinaryLight1 as a class without any sub classes is empty (for lack of better words) and it inherits the attributes properties and methods from its sub classes. You will see this when you get a status update from the Vera. You can see the structure. So I have also made it the same way. I still have yet to output the files for the parent classes but the sub classes are being output almost 100% correctly. I have it building doc strings at the same time and I have a glitch in the code on those that I haven't sorted out yet. I have also found a means to grab a list of category number to category name relationships. The code is in place I still have yet to test it out.

But here is the attached version. test it out. The only thing i have found is that if you have a vera 3 and the wan port on the vera 3 plugged in to your lan you will have to make sure the firewall is disabled. if you are plugged into it's lan ports then it should work.

This script uses UDP broadcasts to 239.255.255.250:1900 which is what UPNP listens on. so if you have a firewall in place to block this or you do not have the Vera on the same network then I can see a potential issue. I am going to work out the means to grab the internal IP from the MIOS servers tomorrow and use UPNP as a fallback.

I have modified the script to allow for the input of the ip address

vera_build.zip

[kdschlosser]

Here is a more updated version. it makes all of the files properly and also make a mapping of category number to name

vera_build.zip

[kdschlosser]

I haven't heard from ya at all. But if you would like to see what I have come up with. I would appreciate your input and suggestions. there could be a better way to go about building the files. not sure tho. The hardest part was making the thing flexible with the service id's and service types because as I have discovered it is riddled with typos and also has no standard to them.

https://github.com/kdschlosser/MiCasaVerde_Vera

[pavoni]

Sorry - been a busy few weeks - afraid it looks like it will continue to another couple of weeks - but would love to take a look...

[kdschlosser]

no worries m8. I am still ironing out some kinks in the code. crazy way MIOS has set up how the Vera references specific variables and methods.

[pavoni]

Yes - I actually removed some of the generic code in pyvera because dealing with the exceptions was harder than explicitly coding the few calls we needed!

[kdschlosser]

The problem I ran into (the first time i made something for the Vera) was that MIOS would change things about that really didn't need any changing. they claim to use UPNP standards which is a half truth. they use a butchered version of it they created. So i said to myself... how to make this thing so it isn't an ongoing maintenance thing that would have to be changed every time they did something. And also how to make it so it would bend and flex with all the various plugins that are available without the need to directly code in support for it. I have been sifting through the Vera quite extensively and have discovered some linux scripts that can be run from the REST API. and allows me to do a variety of things. one of them being list and download files from the Vera. and in those files is all of the information on available functions and the parameters that need to be passed to them as well as all of the various attributes for the different services. and in the device files are all of the different services that specific device type uses. I use this information along with a slew of templates to build python files and i use a class Device(Service, Service, Service) class arrangement to bring all of the tidbits available for each service into a single device.

and because it gathers the information directly from the Vera everything will bend and flex with any changes they make. Now that being said.. the user may have to make adjustments to their code if things change in a manner that would affect them. for instance. if they change the Status variable to State setting that variable directly would require the user to change device.Status = 0 to device.State = 0 but would require no changes to the library to accommodate this change. But if they changed a service name for instance. everything would be seamless to the user and still no changes to the library would need to be made. the user would simply have to rebuild the generated files

[kdschlosser]

I am working on a mechanism to automatically rebuild the files if a change has been made or something new has been installed which there was no file for previously. I already have part of it done with the plugins but I want to make it global to the library. so if the user upgrades the UI on the Vera and that upgrade includes all kinds of new information then the library will know this and rebuild the files.

[kdschlosser]

I know it has been almost a year since I chimed in on this.

Give this a test.
https://github.com/kdschlosser/MiCasaVerde_Vera

It dynamically ports the code on the Vera to python. Plugins. Devices. All of it. There is not a single thing that is not accessable from it. Nice thing is it supports every single plugin made. As well as every device the Vera supports. Now and into the future. No need to do any code maintance or additions. To support new devices/plugins.

The scene end of things I never finished up. I started to think to myself why bother. Better to have the scene run locally.

Another really cool thing that can be done is devices can be created. And custom variables can be made. So you now have the ability to dynamically change information in a device.

As an example. If you wanted to be able to use a follow blown SonyAPI and not just remote control button presses from your Vera. This makes it possible. It removes the handicapped from the vera

[pavoni]

This is an interesting - but very different approach approach.

The code base is currently fairly simple and stable - and there isn't a huge volume of activity - so I feel this is a step too far for this repo at present.