Night and day difference for me. I think I was getting a lot of interference in my media closet. Devices were very slow to respond and sometimes not at all. Switched to UZB and used a USB extender to place it a good 5 ft from the location of my pi. Now things are fast and reliable.

@akbooer said in Delete all device in Room 101:

Yes, absolutely (although I kind of wonder how you reached that figure...!)

The openLuup plugin has an action EmptyRoom101 with the parameter named AreYouSure which requires the value yes (to save nasty accidents.)

Thanks. I see it. They are all old verabridge devices ( and some z-way devices that I had to repair) that are no longer needed as I am fully cloned to z-way and mostly vera free (still have two zigbee door sensors on vera).

Parameters of devices can be set through the api using this URL

YOURIP:8083/ZWaveAPI/Run/devices[DEVICE#].instances[0].Configuration.Set(PARAMETER,PARAMETER_VALUE,size=PARAMETER_SIZE)

Replace:
YOURIP with the IP of Z-way for example 192.168.1.2.
DEVICE# with the Z-way device # of the devices parameter you want to change
Parameter with the parameter # you want to change
VALUE with the Parameter value
PARAMETER_SIZE with the size of the parameter (should be 1, 2, or 4)

An example to change device 51's parameter 3 to a value of 1 with a size of 1:

192.168.1.2:8083/ZWaveAPI/Run/devices[51].instances[0].Configuration.Set(3,1,size=1)

To run it in Luup code

local status, result = luup.inet.wget("192.168.1.2:8083/ZWaveAPI/Run/devices[51].instances[0].Configuration.Set(3,1,size=1)", 5)

@rafale77 It does allow you to subscribe.

You can subscribe to a topic by creating a child device :

Add a new device and choose a type (e.g. "D_BinaryLight1.xml" or "D_TemperatureSensor1.xml").
Reload LUUP engine.
Change the attribut "id_parent" with the id of the MQTT plugin device.
Reload LUUP engine and refresh your browser.
You should see variables "mqttTarget" and "mqttTopic" in your newly created device.
Set the topic you want to subcribe to and the target (format: service,variable=(formula in LUA)).
Reload LUUP engine.
If the payload of the received message is in JSON, the plugin will try to decode it and put it in the variable "payload" in the context of the LUA formula.

@rafale77 said in Delete all device in Room 101:

Congrats on the move! Please report back on positive or negative effects.

Will do. Still working through things and figuring stuff out. So far, the experience has been mostly positive with a few minor hiccups. I also have some scripts I wrote that I plan to share that helped ease my transition.

@rafale77 Have you seen this mqtt plugin? i have been using it to subscribe to topics for some time. Maybe it has some hints as to your issue.

@perh said in Imperihome - missing devices:

While i wait for a replacement app for my local UI devices, i want to use imperihome as long as I can.. But i'm missing a lot of devices!

All Z-Way bridge devices, all security/smoke and motion sensors (local RFXtrx child devices)..

Found the "include vera bridge" in imperihome.lua, what else could cause this?

I had the same issue. Check that the attribute "disabled" is not set to '1' for the missing devices. See this thread

@perh said in Imperihome - missing devices:

While i wait for a replacement app for my local UI devices, i want to use imperihome as long as I can.. But i'm missing a lot of devices!

All Z-Way bridge devices, all security/smoke and motion sensors (local RFXtrx child devices)..

Found the "include vera bridge" in imperihome.lua, what else could cause this?

I had the same issue. Check that the attribute "disabled" is not set to '1' for the missing devices. See this thread

@rafale77 said in MQTT Plugin:

2. the vera-mqtt plugin is full of little bugs causing it to not work as a subscription client. For example the library fails to declare the socket variable, It crashes with an empty socket call to SSL when SSL is not needed etc... I have not been able to make it connect to the mosquitto broker even after fixing all the problems I found...

Sadly, I may have to move back to python and have home-assistant being the MQTT bridge.

I have had good success with the plugin I linked to above. Currently I have 9 different child devices subscribing to at least 15 different topics. I did modify the plugin slightly, not to get it to work, but to allow for child devices to have any designated number of subscriptions, include availability, state, and command topic subscriptions, and I added actions/functions for reconnecting to the mqtt server and reconnecting subscriptions.

I thought it might help with writing your plugin. Looking forward to see what you come up with.

@rafale77 It does allow you to subscribe.

You can subscribe to a topic by creating a child device :

Add a new device and choose a type (e.g. "D_BinaryLight1.xml" or "D_TemperatureSensor1.xml").
Reload LUUP engine.
Change the attribut "id_parent" with the id of the MQTT plugin device.
Reload LUUP engine and refresh your browser.
You should see variables "mqttTarget" and "mqttTopic" in your newly created device.
Set the topic you want to subcribe to and the target (format: service,variable=(formula in LUA)).
Reload LUUP engine.
If the payload of the received message is in JSON, the plugin will try to decode it and put it in the variable "payload" in the context of the LUA formula.

@rafale77 Have you seen this mqtt plugin? i have been using it to subscribe to topics for some time. Maybe it has some hints as to your issue.

@akbooer Ok. I got it. I was able to use the implementation file here to get the switch to function as I expected.

Yes a dummy device. I would expect if I turned the switch on then the variable 'Status' would change to 1 and if I turn it off Status would change to 0. I guess maybe I miss understand and because it is not actually associated with any physical device then Status does not change.

When I manually create a device, the device variables do not update when I manipulate the controls of the created device. I have tried both creating the device through Altui and through luup.create_device. I have tried both a dimmable light and a binary light. Both show up correctly after a luup reload but if I manipulate them to turn on, change dim, etc. the variables never update to reflect the change. For a created binary light device number 226, when I turn it on, the logs show

2020-05-31 12:14:03.747   openLuup.server:: GET /data_request?id=action&output_format=json&DeviceNum=226&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1 HTTP/1.1 tcp{client}: 0x3171c40
2020-05-31 12:14:03.751   luup.call_action:: 226.urn:upnp-org:serviceId:SwitchPower1.SetTarget 
2020-05-31 12:14:03.752   openLuup.server:: request completed (24 bytes, 1 chunks, 3 ms) tcp{client}: 0x3171c40

Not sure what is going on here. Anyone have any ideas?

I am running openluup v20.5.22 and altui v2.49.2547

@CatmanV2 said in Why Migrate to Z-way from vera and how?:

Hmmm so only a partial solution.
Razberry or USB? Razberry is about half the price and would fit nicely on the Pi?

Any other benefit to the dongle?

C

Check out this post with some discussion.

To move from vera bridge to zway, I wrote a script that retrieves the backup reactor file, finds all devices that are referenced in the 10000's, determines there node ID#, generates z-way device numbers in the 20000's based on the node id, and provides a new reactor backup file with the 10000's replaced with the new 20000's. It worked pretty well and saved me a lot of time. Some devices were not fully correct as child device numbers do not seem to be standard. I will share if somebody wants it but I am hesitant because it is not full proof and I am not an expert in lua.