Creating Persistent Variables in Device


I’ve been playing with the X10 plugin to get it working better for me (its invisible in the UI and hangs up regularly) plus as a good example for learning about Vera plugins. I have a few X10 modules around and my alarm system can read/write X10 so I could pick up all these sensors.

It’s been harder than I expected! Managed to develop a json file to make the Cm11 device appear in the standard UI. Also getting close to working out why it is hanging up and have implemented a work around that seems to improve the situation.

Next step is to develop a custom device for each module so that X10 devices can be added on the fly.

How do I build a device definition that creates persistent variables in the device so that I can store the device address?

I’ve put a variable_set command in the lua file referenced in the implementation file and this creates the variable which is visible in the UI under advanced/variables. However I presume it will reset on a engine restart. How do I make the variables persistent and auto created on device creation? Do I do a test variable_get and then a variable_set or is there a better way?

I see this type of thing in the S files which I tried to copy but it did not create the variables:

HouseCode string Address string


Sorry the last line should have been
stateVariable sendEvents=“no”
name HouseCode /name
datatype string /datatype

When you set (or even inadvertently/intentionally create using variable_set) an Advanced > Variable for a device, it remains persistent regardless of Luup restarting, rebooting Vera, etc.

Ask me how I know, ha ha (I even accidentally created one with the same name as an existing one, so have two of them under one of my dimmers).

P.S. Fellow X10 user here. I have a CM11 or CM12 lying around somewhere, but my current Vera setup includes an Insteon interface connected to ftdi_sio via USB on the back of my Vera Plus. It triggers a plug-in Siren if someone futzes with my front door lock too many times. :slight_smile:

P.P.S. New to the Forum? Welcome! FYI, you can click the ‘pencil’ icon to Edit a post or Reply, to spare you having to double-post. :wink:

You can delete variable. Just variable_set with a nill value and the right serviceId.

1 Like

Not see that Insteon device before but I can get one for 50 quid (was looking for a backup CM11 without much joy). It is a better interface than the CM11 and is the protocol well documented? Just programmed a VB interface and Arduino interface from scratch and have spent a while on the Vera one so feeling a little burnt out - so not enthused about starting a new one from scratch unless its significantly better! I think I’ve seen Tx’s from the CM11 starting with another code that is not listed in my CM11 protocol description and this seems to be mucking up the Vera interface. 5B? (might be 5A or which ever is not the normal data waiting polling code).


All I can say at this stage is that X10 took me LOTS of fiddling (both on the original Vera and now its replacement, the Plus) to get working. Think two days devoted solely to figuring out the (barely documented or understandable, to me) USB I/O. The parent company, Mios (and now surely more so with Ezlo) barely acknowledged that X10 could work through Vera, and I think they even tried to talk me out of trying.

Fact is, I have drawers full of perfectly usable X10 equipment, among them controllers that honestly would serve me every bit as well as Z-Wave handheld remotes if I chose to incorporate them into my workflow.

You asked about the interface I’m currently using? Without getting up from the couch, I believe it’s a Smarthome INSTEON PowerLinc Modem Serial 2412S, with an appropriate USB inline adapter. Haven’t sent or attempted to receive any X10 signals in ages, but will happily test again soon if asked.

Reread all the old documentation and sussed the 5B Tx thing. Its something to do with the Cm11 EEPROM, you don’t have do respond to it but you need to read some bytes otherwise it mucks up the algorithm. Think I can see how to make this work reliably now.

Still interested in what that serviceStateTable stuff is in the S file.


You probably already have this info, but here’s a link to my copy of X10 CM11a Interface Protocol…

I also kept all the github stuff for ‘vera-x10-cm11a-controller’ that I found in 2015 on Github. You may wanna give that a google, or ask and I’ll send you a link to my copies.

Edit: Here it is

@LibraSun Very good to know about your work on it.

Sad that I am not technical enough to be able to implement it.

I am just migrating from the old X10 to Z-Wave and I still have several X-10 devices, with a CM15Pro “controller” instead of a CM11 “controller”, but might be not very difficult to adapt your work to the CM15Pro and it would be very nice to take profit of the other X-10 devices still I have for the time they would work OK.

Anyway I will take a note of your references and links.

Thanks again and regards

Cheers LS but already have this.

I’ll post the files once its a bit closer to being presentable. The X10 plugin you can install on the Vera works most of the time but its a bit unreliable - I’ve seen other posts about it hanging and needing to be rebooted every day. After spending way too much time watching the bytes come in I think I’ve spotted the problems and my copy it working a lot better. The current interface is good but there are a few weird things the CM11 does that the plugin did not cater for. Perhaps there are differences.

Z-wave’s a lot nicer of course but I just wanted to spend on my money automating new things rather than replacing what I already have.


1 Like

Hi @raselman, thanks for your information, I will be watching this thread for the case I will be able to use it. Anyway, I have a couple of questions:

Will it be able to work with CM15Pro?
Which way the VERA controller communicates with the X-10 controller (CM11/CM15)?


One of my first devices in 2013 when I first got my Vera 3 and got into Home Automation was an Insteon PLM and an Insteon controller for my garage door. Easy to set up and control. Slowly got other devices but I tried to stay with z-wave - like switches, sensors, etc., as my budget allowed.

After about 2 years, the Insteon stopped working and narrowed it down to the PLM. Replaced it. About a year after that, the garage controller stopped working. That was 3 years total with 100% replacement of the entire Insteon system. I liked the concept, but not the reliability of the hardware. Decided to keep my system z-wave, and ditched Insteon.

I have had a couple of z-wave devices go bad over the years, but I only count 2 out of 15 or so devices. Some I purchased in 2013 or 2014, some I purchased a few months ago.

So if you have X10/Insteon, I can see you wanting to use it. But my experience with the hardware reliability was not positive.

1 Like

UPDATE: All this talk of X10 must have cursed my Vera setup, because literally within days, something quite unexpected and unsettling happened…

In the middle of the night, around 3 AM, my X10 “Siren Module” began beeping (loudly). I had never heard it do that before. And the damn thing wouldn’t stop! Once we figured out where the noise was coming from, I yanked it from the wall and placed it in my “Bound for Workshop” (storage) basket.

Certainly, nothing in Vera had triggered it – indeed, the module had been plugged in for nearly 10 years without so much as a peep – and I can’t imagine my Insteon PLM sending it the precise set of off/on commands necessary for this to happen. In brief, either it became faulty, or my PLM went haywire for no obvious reason … so I’m thinking of retiring that, too.

Because I can’t risk having more random Siren sounds! Sad, because I still cling to the notion that I’d one day take my X10 modules out of hiding and place them in some (non-essential) service – like in the attic or a closet, or plugged in remote controllers – where Z-Wave might otherwise be impracticable.

  • Libra

Best Home Automation shopping experience. Shop at getvera!

© 2020 Vera Control Ltd., All Rights Reserved. Terms of Use | Privacy Policy