Seeking Advice:

[rafale77]

Dec 20, 2019  /  post

How to Recursively Change the File's Permissions in Linux

Linux is a multi-user system and access to the files is controlled through the file permissions, attributes, and ownership. In this article, we'll explain how to recursively change the permissions of files and directories.

sudo chmod -R 777 /etc/cmh-ludl

[PerH]

Isn't that one in the install guide? Anyway, i did that, and GetFiles still didnt get the icons.. So i transferred them manually, and now i have icons after a browser cache clear.

Next hurdle is RFX plugin. I tried once, and failed. Mabye the permissions stopped med back then..

[PerH]

Ok, so RFX Plugin is installed and working. Anyone here have it? Mine shows
Firmware Type: false Firmware Version: false

other than that its working.

Also tried to hijack the sensors by changing ID and parent ID. It worked, but the statistics (shown in "Temperature and Humidity Sensor Data") are from the remote unit..
Any tips to making a script that hijacks all sensors?
Then I could exclude the RFX from verabridge, and be one step more along..

[akbooer]

@PerH said in Another transition from Vera to OpenLuup - PerH:

Also tried to hijack the sensors by changing ID and parent ID. It worked

Did it, really?

I'm not familiar with this particular plugin, but this is very unlikely to be something that you would want to do for any device. What problem do you see this as fixing?

[a-lurker]

@PerH said in Another transition from Vera to OpenLuup - PerH:

Firmware Type: false Firmware Version: false

Sounds similar this issue. Have a read through the next few posts at that link; may be same.

It would be good, if we could encourage TinMan to place the USB RFXtrx code on GitHub; so any changes could be kept track of.

[CatmanV2]

Ref the icons, you might want to have a read of my thread 'What I did on my holidays'. I ended up transferring mine manually using command line tools.

C

[PerH]

@akbooer said in Another transition from Vera to OpenLuup - PerH:

@PerH said in Another transition from Vera to OpenLuup - PerH:

Also tried to hijack the sensors by changing ID and parent ID. It worked

Did it, really?

I'm not familiar with this particular plugin, but this is very unlikely to be something that you would want to do for any device. What problem do you see this as fixing?

If this could be done with a script, i won't have to find, and name about 50 433 devices (including child and group devices)..

The 3 sensors i tried works fine, but i don't know how the device parameters are stored in the system.. I did this earlier between RFX'es connected to the same unit as well, back then i didnt have to change the device ID, just the Parent ID..

@a-lurker said in Another transition from Vera to OpenLuup - PerH:

@PerH said in Another transition from Vera to OpenLuup - PerH:

Firmware Type: false Firmware Version: false

Sounds similar this issue. Have a read through the next few posts at that link; may be same.

It would be good, if we could encourage TinMan to place the USB RFXtrx code on GitHub; so any changes could be kept track of.

Same issue, same person.

No conclusion other than inserting ToString(), which removes the symptom, not the problem..

I read your post, and ended up doing the same thing.. i have icons now.

[PerH]

so - if i were to try something like this:

for (all devices) do
   if device.IDparent = 11 then 
      device.IDparent = 72
      device.ID = (next free dev.ID number)
   end if
end for

How would that be done in lua with the openluup device list?

[akbooer]

You’re trying to clone the device, as well as giving it a new parent? Do you know if that’s necessary?

All the usual luup calls for creating child devices are available to you.

[PerH]

Not knowing the system - i'm trying to reassign the device to a new parent.
I tried just changing the parent, but then VeraBridge corrected the variable change on reload.
When i changed the deviceID as well, a new VeraBridge device popped up on reload. I can live with that, when i've reassigned all the 433 devices to the local RFXTRX, i'll just mask out the Vera RFX in vera bridge.

As i don't know the usual luup calls, i was hoping to cut the corner by asking you guys?

[akbooer]

If this is a bridged device, then you’ll have to make the changes on Vera. The openLuup bridge simply reflects the configuration that it sees on the Vera. Anything (except action commands, device name, etc.) sent to the device locally will get overwritten on the next update.

[PerH]

Ok, i'll try to specify more:

The Vera is connected to AltUI using the bridge. The vera has a RFXTRX433 connected with more than 60 child devices.
These are bridged to AltUI, with the 10000 numbers. RFX plugin on vera is device 10011 in AltUI.

The Openluup ALTUI Chromebox that i want to migrate them to Also has a RFXTRX433 connected. This plugin device is AltUI device 72.

If I go to the variables on one of the children of the Vera RFX - say device ID 10237 - and change ParentID from 10011 to 72, and at the same time changes the DeviceID from 10237 to - say 80 - this child device becomes a local device - Child of '72.
When I remove the RFX 10011, all the children also disappears, but I still have the ones i changed, and they now work with the local RFX plugin.

If I could run a script that changes DevID and ParentID, I would get all sensors over without having to set up the names and transfer codes for all devices.
I however don't know the correct lua syntax to do it.

[akbooer]

OK, much clearer as to what you're trying to do. Let me think a while on this.

[akbooer]

@PerH said in Another transition from Vera to OpenLuup - PerH:

so - if i were to try something like this:

for (all devices) do
   if device.IDparent = 11 then 
      device.IDparent = 72
      device.ID = (next free dev.ID number)
   end if
end for

How would that be done in lua with the openluup device list?

Backup first, of course, but let's try this:

local oldparent = 23    -- *** CHANGE THESE ***
local newparent = 315

for i, d in pairs (luup.devices) do
  if d.device_num_parent == oldparent then
    local id = luup.create_device()       -- get a new device (number)
    print (i, d.device_num_parent, id)
    luup.devices[id] = d                  -- apply new device number
    luup.devices[i]  = nil                -- remove it from old one
    d.attributes.id_parent = newparent    -- give it a new parent
    d.device_num_parent = newparent
    d.attributes.room = 0                 -- and a new (no) room
    d.room_num = 0
  end
end

Follws by a restart.

This may, or may not, work. It is trickier that you might suppose, and without a test plugin, I can't really tell...

[PerH]

Thanks! I'll try later.. My system isn't doing anything important yet anyway.

[PerH]

No success on first attempt.. i'll have a new stab at this later.
Where does plugins store their tables? i see in the code that the plugin stores several tables somewhere?

[akbooer]

Yes, it’s the plugins which are the real issue here.

The multiple assignment in the above code, though, are entirely due to Vera’s very poor internal implementation of some features, which openLuup had to emulate.

It would be possible to edit the user_data.json file where all the information is stored between reloads.

[PerH]

Coming back to this, I found that the code actually did work! I didn't think so, as all the created devices was invisible, and said "no such device" in the device list in openluup.. 6 days later, all sensors are populated and functioning.

The UZB has now arrived, so i guess the next step is getting the z-wave stuff over.

[PerH]

Ok, so Z-way is now installed and GUI is working, but before I buy the (hopefully one-time?) license:
Is there other Open-source alternatives to get z-wave to openluup?
Is the device compatibility list better than vera? (can't seem to find it anywhere!)
will the altUI mesh-map work with z-way integration?

I found the demo license button now, but can't update the vendor list.. and i can't find the two devices i tested..

[rafale77]

Seems like I can help on this:

1. The only open source z-wave library that I know of is... openzwave. It is what home-assistant, openhab and domoticz uses. It honestly is much better now than vera but not as good as z-way but is also undergoing significant development.
2. There is no device compatibility list because it is just compatible with zwave. All zwave devices should work. There is no custom gizmoing around configurations the way vera has done it. So yes device compatibility is limitless.
3. The mesh map could be made to work but does not at the moment. It is built off of the neighbor's list property which the bridge is not publishing from z-way at the moment. z-way UI has it's own neighbor mesh visualization.

The license is attached to the uzb itself and it is something I don't like. Is the uzb fails, you lose the license. It has not happen to me yet but I am really not a fan of this method that's why I got a couple of razberries as backup but their antenna is not nearly as good as the uzb and require a rPi.