OK, so ignore the documentation and just do the four commands I listed in that post. It is not one-click, but typing four lines is not too hard.
FYI, the easiest way to update either of these to the latest from the master branch is simply to go to the Plugins page and click the update button against the appropriate plugin.
FYI, the easiest way to update either of these to the latest from the master branch is simply to go to the Plugins page and click the update button against the appropriate plugin.[/quote]
0.latest is the latest. otherwise it is when I formalize a release. I intend to put quick bugfix directly available under 0.latest
[quote=“CudaNet, post:20, topic:192902”]Observed an error… This was using the latest Git for Raz… Same thing for 0.latest from AppStore…
2016-07-09 19:47:14.994 luup_log:5: RAZB: debug: resyncZwayDevices(5)
2016-07-09 19:47:14.995 openLuup.context_switch:: ERROR: [string "[5] I_RAZB.xml"]:654: bad argument #1 to 'ipairs' (table expected, got nil)
2016-07-09 19:47:14.995 luup.delay_callback:: function: 0x1e63bf0 ERROR: [string "[5] I_RAZB.xml"]:654: bad argument #1 to 'ipairs' (table expected, got nil)
2016-07-09 19:47:15.502 openLuup.server:: request completed (1743 bytes, 1 chunks, 7708 ms) tcp{client}: 0x1e73868
2016-07-09 19:47:15.605 openLuup.server:: /data_request?id=lu_status2&output_format=json&DataVersion=111623411&Timeout=60&MinimumDelay=1500&_=1468111589955 tcp{client}: 0x1e73868
[/quote]
I have tried to check in a quickfix in 0.latest
Thanks AK and Amg0… I’m now used to the AppStore but I often forget about the plugins…
FYI, the easiest way to update either of these to the latest from the master branch is simply to go to the Plugins page and click the update button against the appropriate plugin.[/quote]
All is well now. 1 device created. Let me know if you need anything (logs etc…).
[quote=“amg0, post:24, topic:192902”][quote=“CudaNet, post:20, topic:192902”]Observed an error… This was using the latest Git for Raz… Same thing for 0.latest from AppStore…
2016-07-09 19:47:14.994 luup_log:5: RAZB: debug: resyncZwayDevices(5)
2016-07-09 19:47:14.995 openLuup.context_switch:: ERROR: [string "[5] I_RAZB.xml"]:654: bad argument #1 to 'ipairs' (table expected, got nil)
2016-07-09 19:47:14.995 luup.delay_callback:: function: 0x1e63bf0 ERROR: [string "[5] I_RAZB.xml"]:654: bad argument #1 to 'ipairs' (table expected, got nil)
2016-07-09 19:47:15.502 openLuup.server:: request completed (1743 bytes, 1 chunks, 7708 ms) tcp{client}: 0x1e73868
2016-07-09 19:47:15.605 openLuup.server:: /data_request?id=lu_status2&output_format=json&DataVersion=111623411&Timeout=60&MinimumDelay=1500&_=1468111589955 tcp{client}: 0x1e73868
[/quote]
I have tried to check in a quickfix in 0.latest[/quote]
And for those in the U.S. wanting (F) instead of (C)… Here’s some quick directions…
(Raspbian Jessie)
[1] Log in via SSH.
[2] root level: cd /
[3] elevate permissions: sudo su
[4] transition to proper directory: cd /opt/z-way-server/config
[5] nano (or other editor): nano Defaults.xml
[6] within the node, locate the following sub-nodes and modify accordingly:
where 0 = (C) and 1 = (F); 0 = default value.
<SensorMultilevel>
<Fahrenheit>1</Fahrenheit><!-- Default scale to use -->
</SensorMultilevel>
<ThermostatSetPoint>
<Fahrenheit>1</Fahrenheit><!-- Default scale to use -->
</ThermostatSetPoint>[7] cntrl-o, press enter and cntrol-x
[8] reboot
Give z.way some time to adjust. At first the z-way consoles (both Expert and SmartHome) displayed a negative int.
Hope this helps…
Just an update on the plugin progress…
Here’s a device page snapshot of a system with:
[ul][li]Everspring door sensor[/li]
[li]Everspring dimmer module[/li]
[li]Fibaro RGBW controller[/li]
[li]Everspring ST-814 temperature/humidity[/li]
[li]Aotec MiniMote 4-button controller[/li]
[li]Aotec Multi-sensor 3[/li][/ul]
and also a Parent/Child diagram showing the correct tree structure relationship between the plugin and the multi-sensors.
Currently, though, only the two motion detectors actually work (one can be seen activated in the screen shot) … there is actually a very, very long way to go to get it all working.
I also have a Aeotec 6 in 1 multi sensor, although mine isn’t showing the nice picture in the Z-Way expert interface like CudaNet has. I just paired an Aeotec recessed door sensor. I’m not sure exactly what information would be helpful, but I’ll try to include everything CudaNet did for now. If you need something else, just let me know.
More screenshots in case it is helpful.
And a conceptual question:
In getting the Caseta Plugin working I ultimately had to grab a number of D_ and S_ files from /etc/cmh-lu on the Vera itself. This of course requires using pluto-lzo to decompress them. I assume for the time being more of these files are going to be necessary, but going forward will some of them be re-created and/or specialized for the OpenLuup environment?
Interestingly without them I was able to add the Caseta Bridge, it auto created all the devices as usual, and I could control them via the AltUI devices section. The issue came when trying to do scenes or workflows as they didn’t list any available actions. Adding the /etc/cmh-lu files made those actions show up.
Also as a side note to others playing around with this, on my first attempt I had the Caseta plugin working well, but without actions. So I started adding those files. Eventually things got a little weird, so I reinstalled OpenLuup and used my user_data.json file (with only the Caseta bridge added, I let it reconfigure the devices automagically). After doing that I could see the Caseta devices and their actions. However I couldn’t control them either with automation, or just in the devices section. I’m not sure what went wrong, but the LuaUPNP.log showed a lot of TCP errors, and either 0 bytes sent or -1 for each command I tried to send. I wiped out all the Caseta and OpenLuup files and reinstalled all again and that fixed it.
I don’t think there is too much doubt that the RaZberry board and the Z-Way software works well on its own. The trick is to get it going with AltUI and openLuup.
In getting the Caseta Plugin working I ultimately had to grab a number of D_ and S_ files from /etc/cmh-lu on the Vera itself.
Yes, because as it stands, the openLuup environment is an emulation of Vera.
This of course requires using pluto-lzo to decompress them.
In fact, not. You can with retrieve individual, uncompressed file from Vera with an HTTP command (or use the UI) or you can use the single action that the VeraBridge plugin offers to download ALL the files, uncompressed, in the form that openLuup needs them.
I assume for the time being more of these files are going to be necessary, but going forward will some of them be re-created and/or specialized for the OpenLuup environment?
As per the above, openLuup needs them, because Vera needs them. A very significant number of useful plugins also rely on them - they are not just for Zwave devices. Of course with a significant amount of engineering some of this could go away. It’s worth noting that a lot of the baggage that comes in the form of these files is nothing proprietary to MCV / Vera, but is just standard UPnP. Ironically, openLuup doesn’t actually do UPnP, in the open communication/device discovery sense.
Interestingly without them I was able to add the Caseta Bridge, it auto created all the devices as usual, and I could control them via the AltUI devices section. The issue came when trying to do scenes or workflows as they didn't list any available actions. Adding the /etc/cmh-lu files made those actions show up.
Yes, exactly so. The device files tell which services to create, the service files define what they are to AltUI. openLuup itself has little to no need of either, and it’s possible to write perfectly functional devices without them. For example, almost none of the actions which VeraBridge or, indeed, the RaZberry plugin respond to are defined that way.
Looks like the Schlage BE469 z-wave locks may be a problem (unless I can figure out how to teach z-way to manage it properly). Interview went flawless but the lock appears to shut down it’s wireless and therefore I cannot lock/unlock. Firmware appears to be key here after searching through the z-way forum. The lock I was working with today has the following:
FirmwareInfo: 59,26645,0
ManufacturerInfo: 59,25409,20548
Capabilities: 83,220,0,4,64,3,R,B,RS,W1,|32S,34,93S,98S,99S,112S,113S:3,114,122,128S,133S,134,152,This is just an FYI, I’d expect that anyone having issues with a device within z-way would inquire within the z-way forum for support.
[url=http://www.schlage.com/content/dam/sch-us/documents/pdf/installation-manuals/24352403.pdf]http://www.schlage.com/content/dam/sch-us/documents/pdf/installation-manuals/24352403.pdf[/url]
Sorry, realized after reading this I forgot some of the most potentially helpful screenshots, the ones where it appears in AltUI/OpenLuup. I’m attaching the missing ones to this post.
Thanks for the other info also. I think I had read about the HTTP method before and just forgot when I got heads into getting things working. What I really need to do is write a shell script to iterate through the entire directory, decompress them, then scp them to the PI. That way I can just grab all of them in one swoop and not have to worry about it. I’m making sure to keep any Vera original ones in the /etc/cmh-lu folder so that if future versions of OpenLuup/AltUI have alternate ways of handling the control I can easily rename the folder to test.
I’m not much of a coder, I’ve done a bit of PHP, Powershell, and bash scripting, and mostly know enough to tweak things to make stuff work together or build something based on an existing framework. But I want to help in any way that I can. I’m pretty familiar with installing and configuring things on Linux, grabbing log files, and digging around to find solutions to issues. I’m extremely new to both Vera and Lua, so I may need some guidance to provide what you might find most helpful.
Ah… I think I just had a light bulb moment, once you have an OS loaded then it all loads. what I wasn’t seeing was that you already had an OS loaded and going whilst I was looking at it from a razberry with nothing loaded.
That shows it as an ‘unrecognised’ device.
What I really need to do is write a shell script to iterate through the entire directory, decompress them, then scp them to the PI. That way I can just grab all of them in one swoop and not have to worry about it.
You don’t need to do that, it’s all been done for you. Just connect to Vera using openLuup’s VeraBridge plugin (built-in) and click on the single action button ‘GetFiles’. It will download all device files into the files/ folder and all icons into the icons/ one.
That shows it as an ‘unrecognised’ device.
What I really need to do is write a shell script to iterate through the entire directory, decompress them, then scp them to the PI. That way I can just grab all of them in one swoop and not have to worry about it.
You don’t need to do that, it’s all been done for you. Just connect to Vera using openLuup’s VeraBridge plugin (built-in) and click on the single action button ‘GetFiles’. It will download all device files into the files/ folder and all icons into the icons/ one.[/quote]
.latest version on the alt app store should contain a version that can create devices for the various sensors when they are embedded in a multisensor device like hte 6in1
for memory, this is ALPHA level software, but quite interested in experiences. esp the 6 in 1 AEON.
to test, please update the plugin , delete your old devices ( the parent) and reload
[quote=“amg0, post:36, topic:192902”].latest version on the alt app store should contain a version that can create devices for the various sensors when they are embedded in a multisensor device like hte 6in1
for memory, this is ALPHA level software, but quite interested in experiences. esp the 6 in 1 AEON.
to test, please update the plugin , delete your old devices ( the parent) and reload[/quote]
Yup, it is working. I actually had updated OpenLuup, AltUI, and Razberry last night at about midnight CDT, and when the Luup reload finished the sub devices were there. Before that it was just the main unit. I went ahead and updated again, and deleted the main unit and it recreated the sub units again. The temperature and Humidity sub-devices appear to be showing correct values also.
I discovered I had param 5 set to a value of ‘1’ (send basic report) for the 6 to 1. My bad… Had to set it to ‘2’ (Send Sensor Binary Report CC.) and now I see last trip and last untrip.
I’ll provide more detailed observations when I get a chance. In the meantime, I’ll attach logs.
Hi amg0,
is there an idea about a remote connection to the system without the use of a VPN ? Is it possible a Vera-like solution ? or a simple VPN solution integrated in the RPI-Razberry-Openluup-ALTUI system ?
tnks
donato
There’s already two working approaches to this:
[ul][li]Misc > Remote Access Login[/li]
[li]and weaved.com [/li][/ul]