The keypad image is loaded from the external javascript for the implementation of the panel device… looks like it’s baseurl in altui is causing it to be “not found”…
A fix is forthcoming…
Perfect, thank you.
[quote=“cybrmage, post:21, topic:190783”]The keypad image is loaded from the external javascript for the implementation of the panel device… looks like it’s baseurl in altui is causing it to be “not found”…
A fix is forthcoming…[/quote]
Actually, I hope that’s [tt]{ip_address}/cmh/skins/default/icons/filename.png’[/tt]
Can you confirm?
I’ve been shamed… Shame, Shame !!! Yes, you are correct. I (thinking of excuse) ummmmm… Oh well.
Actually, I hope that’s [tt]{ip_address}/cmh/skins/default/icons/filename.png’[/tt]
Can you confirm?[/quote]
The EVL3Vista update (v4.0.12) with icon and keypad image fixes is posted HERE
Cybrmage, AltUI is indicating an error [Failed to load resource: the server responded with a status of 404 (Not Found)] regarding the URL for that image.
http://10.0.4.122/cmh/skins/default/vista_partition_device_keypad.pngLooks like it’s expecting:
http://10.0.4.122/cmh/skins/default/icons/vista_partition_device_keypad.pngI had intended to move the image to the non-standard location… As I was having trouble detecting the UI version when running on openluup… and it seemed to work on my dev systems…
BUT… the changes were a total screwup… They broke other things… totally screwed up user code management and zone editing…
So… here is another try… I have tested it on Vera UI5 and UI7 and on openluup, and it seems to fix the issues…
v4.0.13 is in the EVL3 “LATEST VERSION” thread.
Things look solid, If I run into any issues I’ll continue to post here. I HUGE thanks for working through these issues, I truly appreciate it…
[quote=“cybrmage, post:27, topic:190783”]I had intended to move the image to the non-standard location… As I was having trouble detecting the UI version when running on openluup… and it seemed to work on my dev systems…
BUT… the changes were a total screwup… They broke other things… totally screwed up user code management and zone editing…
So… here is another try… I have tested it on Vera UI5 and UI7 and on openluup, and it seems to fix the issues…
v4.0.13 is in the EVL3 “LATEST VERSION” thread.[/quote]
Just let me know if you find openLuup is not compatible with the way Vera does something (except, of course, constant reloads.)
Aww… But I’m used to the constant reloads… 8-}
I’m still having issue with device icons… but I think it’s related to AltUI rather that openluup. The EVL3Vista panel device uses a json file that specifies both “flashicon” and “default_icon” so that it will work with both UI5 and UI7 without the need for UI specific files. Although openluup reports that it is “UI7”, AltUI always displays the UI5 “flashicon”.
The plugin also uses custom device files for security sensors… These device files specify the standard device type with a custom json file. This is done primarily as a workaround to remove the “Arm”/“Disarm” button from UI7 and substitute a “Bypass” button, as it interferes with house modes. This does not work in UI5 (which substitutes the default json for the device type), but It does work in UI7. The AltUI debug console reports “ALTUI v1.10:_getDeviceStaticData(0-30) does not find static data” and “ALTUI v1.10:Icon for device id:0-30 DeviceType unknown or not static data”… I have not yet determined if this is openluup processing the json file into static data, or AltUI not processing the data because it doesn’t match what is expected for the device type…
Sorry… but you did ask 8-}
openLuup does absolutely nothing with .json files except put them into the static_data structure when the user_data is requested. The decision, early on, not to implement Vera’s deeply flawed triggers and notifications, plus the lack of any native openLuup UI (thank you AltUI for the alternative!) means it doesn’t need them. They are, however, cached, to avoid redundant file reads, and indexed by filename.
The plugin also uses custom device files for security sensors... These device files specify the standard device type with a custom json file... I have not yet determined if this is openluup processing the json file into static data, or AltUI not processing the data because it doesn't match what is expected for the device type...
Do the device attributes show the correct device file and json file in the Attributes panel of the device in AltUI? In order to allow the user_data to override the device file declarations (specifically needed for a device to change its static json file, as many do when switching between UI5 and UI7) the attribute information takes precedence in openLuup.
Sorry... but you did ask 8-}
I love this sort of question because it gives just a hint of the difficulties that us developers have in either using or, worse, reverse-engineering, a system without any significant documentation.
Ohhhh… - I’m loving this. Vera is senescing. If it restarts by itself again, real soon, that’s it. Please keep up the intrigue.
I haven’t yet put this fix onto GitHub, because I’m not convinced about the statement on timeouts.
I wrote this little program to test it:
local socket = require "socket"
local timeout = 10
local port = 1234
local ip = "127.0.0.1"
local function print (...)
_G.print (os.date "%H:%M:%S", ...)
end
local sock, msg = socket.tcp ()
if sock then
sock:settimeout (timeout)
sock:setoption ("tcp-nodelay", true) -- so that alternate read/write works as expected (no buffering)
print "connecting..."
ok, msg = sock:connect (ip, port)
print "receiving..."
local data, msg = sock:receive ()
print (data or msg)
sock: close()
else
print "not connected"
print (msg)
end…and simply ran this unix command so that it had something to connect to:
nc -l 127.0.0.1 1234Doing nothing, I got:
16:20:29 connecting...
16:20:29 receiving...
16:20:39 timeout
Program completed in 10.01 seconds (pid: 4199).Typing “test” into the nc program gave me:
16:22:04 connecting...
16:22:04 receiving...
16:22:05 test
Program completed in 1.17 seconds (pid: 4201).So, in my understanding, the timeout value IS in SECONDS, but it has MILLISECOND precision because it can be a decimal number.
Your thoughts on this?
[quote=“akbooer, post:33, topic:190783”]So, in my understanding, the timeout value IS in SECONDS, but it has MILLISECOND precision because it can be a decimal number.
Your thoughts on this?[/quote]
I just did some tests (using io.lua unchanged), with the EVL3Vista plugin…
On a Vera unit, Passing a timeout = 0, the luup.io.read function waits for data indefinitely… on openluup, it returns a timeout.
On a Vera unit, Passing a timeout = 1, the luup.io.read function waits for data for 1 second… on openluup, it returns a timeout immediately.
On a Vera unit, Passing a timeout = 1, the luup.io.read function waits for data for 10 seconds… on openluup, it returns a timeout immediately.
I think it will be safe to leave the read timeout the way it is… it is easy enough to work around in the plugin, and the differences in functionality may actually be related to the version of Luasocket installed on the system.
On a (vaguely) related note… The logging function seems to be “broken” for the io.lua file… The log entry for the io functions does not display the device number associated with the log entry…
IE:
the current _log function,
local function _log (msg, name) logs.send (msg, name or _NAME) endproduces:
2016-01-30 10:39:07.570 luup.io.incoming:: bytes received: 1, status: OKIf I change the _log function in io.lua to:
local function _log (msg, name) logs.send (msg, name or _NAME, tonumber (device) or scheduler.current_device()) endIt then displays the correct device number associated with the logged action.event.
2016-01-30 11:29:36.287 luup.io.incoming:26: bytes received: 1, status: OKI think this is a typo?
...the differences in functionality may actually be related to the version of Luasocket installed on the system.
Hugely likely. Many of the binary installs for LuaSocket are hopelessly out of date (by several years.)
Could you possibly re-run your tests with the attached io.lua file, which implements timeouts differently? (uses socket.select)
On a (vaguely) related note... The logging function seems to be "broken" for the io.lua file... The log entry for the io functions does not display the device number associated with the log entry...
Can you tell me if this is for calls to io.read() or to the incoming handler? The device context may be missing for the latter since part of the code may be run in the system context, not that of the device itself.
Thanks again!
Edit: I have modified the log messages to include the socket ID, as most other socket-related logs do, so it should be clearer.
yes 8-{
I will give it a try…
It seems to be for both… basically any logging…
2016-01-30 10:39:04.928 luup.io.read:: bytes received: 1, status: OK
2016-01-30 10:39:07.298 luup.io.open:: connecting to 192.168.1.54:4025, using crlf protocol
2016-01-30 10:39:07.299 openLuup.io:: connect OK
2016-01-30 10:39:07.520 luup.io.write:: message length: 8, bytes sent: 8, status: OK
2016-01-30 10:39:07.522 luup.io.incoming:: bytes received: 1, status: OKand the quick fix I did seems to resolve it…
2016-01-30 11:22:08.925 luup.io.open:65: connecting to 192.168.1.54:4025, using crlf protocol
2016-01-30 11:22:08.927 openLuup.io:65: connect OK
2016-01-30 11:22:09.169 luup.io.incoming:26: bytes received: 1, status: OK
2016-01-30 11:22:09.173 luup.io.incoming:65: bytes received: 6, status: OK
2016-01-30 11:22:09.180 luup.io.write:65: message length: 8, bytes sent: 8, status: OK
2016-01-30 11:22:09.183 luup.io.incoming:26: bytes received: 1, status: OK
2016-01-30 11:22:09.184 luup.io.incoming:65: bytes received: 2, status: OK
2016-01-30 11:26:09.489 luup.io.write:65: message length: 10, bytes sent: 10, status: OK
2016-01-30 11:26:13.479 luup.io.read:65: bytes received: 21, status: OKAs you can see… with multiple plugins using the IO subsystem, it helps knowing which device the log message is related to…
[quote=“cybrmage, post:36, topic:190783”]It seems to be for both… basically any logging…
[…]
As you can see… with multiple plugins using the IO subsystem, it helps knowing which device the log message is related to…[/quote]
You may not have seen this edit to my previous post:
Edit: I have modified the log messages to include the socket ID, as most other socket-related logs do, so it should be clearer.
However, I’ll include your modification too, thanks
Here are the results:
- plugin code restored to original timeout of 0 (zero).
2016-01-30 15:49:53.756 luup_log:65: (EVL3VistaAlarmPanel::discoverPanelConfig) Testing installer code.
2016-01-30 15:49:54.008 luup.io.read:: error: timeout tcp{client}: 0x919f40
2016-01-30 15:49:54.259 luup.io.read:: error: timeout tcp{client}: 0x919f40
2016-01-30 15:49:54.511 luup.io.read:: error: timeout tcp{client}: 0x919f40
2016-01-30 15:49:54.763 luup.io.read:: error: timeout tcp{client}: 0x919f40
2016-01-30 15:49:55.015 luup.io.read:: error: timeout tcp{client}: 0x919f40
2016-01-30 15:49:55.267 luup.io.read:: error: timeout tcp{client}: 0x919f40
2016-01-30 15:49:55.519 luup.io.read:: error: timeout tcp{client}: 0x919f40
2016-01-30 15:49:55.521 luup.io.write:: message length: 8, bytes sent: 8, status: OK tcp{client}: 0x919f40
2016-01-30 15:49:55.523 luup.io.read:: error: timeout tcp{client}: 0x919f40
2016-01-30 15:49:55.524 luup_log:65: (EVL3VistaAlarmPanel::discoverPanelConfig) FAILED: Default Installer Code incorrect.(Note: the first 7 errors are expected, as the code tries to make sure there is no pending data.)
Code changed to specify a timeout of 1:
2016-01-30 16:00:47.633 luup_log:65: (EVL3VistaAlarmPanel::discoverPanelConfig) Testing installer code.
2016-01-30 16:00:48.886 luup.io.read:: error: timeout tcp{client}: 0xa97f00
2016-01-30 16:00:50.139 luup.io.read:: error: timeout tcp{client}: 0xa97f00
2016-01-30 16:00:51.392 luup.io.read:: error: timeout tcp{client}: 0xa97f00
2016-01-30 16:00:52.309 openLuup.context_switch:: ERROR: ./openLuup/io.lua:213: bad argument #1 to 'receive' (string expected, got userdata)
2016-01-30 16:00:52.310 luup.delay_callback:: function: 0x8990b8 ERROR: ./openLuup/io.lua:213: bad argument #1 to 'receive' (string expected, got userdata)Code changed to specify a timeout of 1000:
2016-01-30 16:09:16.044 luup_log:65: (EVL3VistaAlarmPanel::discoverPanelConfig) Testing installer code.
2016-01-30 16:09:22.866 openLuup.context_switch:: ERROR: ./openLuup/io.lua:213: bad argument #1 to 'receive' (string expected, got userdata)
2016-01-30 16:09:22.868 luup.delay_callback:: function: 0x212c9b8 ERROR: ./openLuup/io.lua:213: bad argument #1 to 'receive' (string expected, got userdata)It appeasr that you have called sock:receive() instead of receive() on line 213…
After fixing that typo ( 8-} )… A timeout value of zero gives the same error as above, and a timeout value of 1 works properly with no errors.
Yes… I did miss your update…
The added “socket ID” does not help…
2016-01-30 16:36:36.547 luup.io.read:: bytes received: 51, status: OK tcp{client}: 0x1749588There is no direct correlation between the socket ID and the device that owns the socket.
Yes, I tested the socket.select() approach in the test program I posted earlier, and then just pasted the code into io.lua. Shame on me again.
The 0 timeout needs to be mapped to nil before the read() for this to work, but I think that’s fixable, so we are close. You really use this? It will block everything else.
Thanks.