I have a plugin that uses the raw protocol. As each byte comes in the log files prints the following:
2017-04-10 18:55:48.919 luup.io.incoming:8: bytes received: 1, status: OK tcp{client}: 0x3207878
2017-04-10 18:55:48.919 luup.io.incoming:8: bytes received: 1, status: OK tcp{client}: 0x3207878
2017-04-10 18:55:48.920 luup.io.incoming:8: bytes received: 1, status: OK tcp{client}: 0x3207878
2017-04-10 18:55:48.926 luup.io.incoming:8: bytes received: 1, status: OK tcp{client}: 0x3207878
2017-04-10 18:55:48.926 luup.io.incoming:8: bytes received: 1, status: OK tcp{client}: 0x3207878
2017-04-10 18:55:48.926 luup.io.incoming:8: bytes received: 1, status: OK tcp{client}: 0x3207878
2017-04-10 18:55:48.926 luup.io.incoming:8: bytes received: 1, status: OK tcp{client}: 0x3207878
2017-04-10 18:55:48.926 luup.io.incoming:8: bytes received: 1, status: OK tcp{client}: 0x3207878
2017-04-10 18:55:48.926 luup.io.incoming:8: bytes received: 1, status: OK tcp{client}: 0x3207878
The problem is that each RX’ed block is 512 bytes long. So the log file is full of these, as a block read is done every minute. It’s also ups the CPU usage a lot, as each incoming byte results in the additional overhead of reporting it in the log file.
Can this reporting be adjusted to minimise the logging some how?
As I understand it, openLuup interval timers are immune to CPU reboots or Luup engine restarts, unlike Vera timers, which are not. With Vera Futzel’s Countdown timer plugin solves this oversight (now superseded by workflows, etc.)
Is my understanding correct? If so, can the documentation PDF be modified to reflect this? Also are the interval timers retriggerable or non retriggerable one shots?
Can our Linux experts suggest a way forward on what could potentially be included with openLuup? Noting that the various hardware platforms in use by openLuup may be problematic.
[quote=“a-lurker, post:101, topic:189405”]I have a plugin that uses the raw protocol. As each byte comes in the log files prints the following:
[…]
Can this reporting be adjusted to minimise the logging some how?[/quote]
The latest update to the development branch (2017.04.10) now has a parameter which controls this.
In Startup Lua, you can disable incoming logging with the line:
Not quite. AFAIK, scheduled scenes in Vera run just fine over reboots/restarts, as do openLuup ones. What fails, in both systems, are incomplete delayed scene actions. This is why it’s a good idea to have separate scenes for, say, on/off, rather than trying to put it all into one. Of course, openLuup doesn’t spontaneously restart, unlike Vera, so it’s not an issue.
Also are the interval timers retriggerable or non retriggerable one shots?
As per the ‘Vera/MiOS standard’, interval timers called from luup.call_timer() are only one-shot. However, to me this seemed such a terrible omission, that I added an optional parameter at the end of the openluup call to make them recurrent…
luup.call_timer (fct, timer_type, time, days, data, recurring)
Simply set recurring to true to make this happen BUT be very careful that your callback code does not make another call to call_timer() otherwise you will generate an exponentially growing number of scheduled callbacks.
Using this feature:
[ul][li]breaks compatibility with Vera/MiOS, but…[/li]
[li]…ensures that scheduled callbacks occur exactly when they should, and don’t ‘slip’ because of the execution time of the callback code.[/li][/ul]
[quote=“a-lurker, post:103, topic:189405”]openLuup using Lua 5.1 doesn’t have a bit library available:
[…]
Can our Linux experts suggest a way forward on what could potentially be included with openLuup? Noting that the various hardware platforms in use by openLuup may be problematic.[/quote]
I don’t see this as an openLuup problem, per se, since openLuup doesn’t need one. The configuration of Lua 5.1 on your target system is not part of the system installation (simply because it is machine-dependent.)
If you need a bit library for a special plugin, then you have a range of options:
It’s great to see that the user_data.json is pretty printed in openLuup. With Vera I always had to get this done first before proceeding - total pain. As a further refinement could the the device descriptions be sorted by device id when the file is every written out - including the Vera Bridge devices? The rooms and scenes already seem to do this.
I can’t imagine why you’re needing to look through the user_data? I’m sure there must be a better way to find out whatever it is you’re hunting for there. However, latest development branch 2017.04.19 has the fix.
user_data.json has been my migratory home of late. Take the 10,000 offset off the device and its children and change the parent from Verabridge to openLuup. Make sure the implementation file is correct rather than “X’”. Keep an eye on “Device_Num_Next” having the right value and away you go. I thinking I’m heading for a fall, as I haven’t checked out what the numbering system of these do? We need them but the numbering means what. Hacking the user_data.json allows easy change to lots of stuff but one mistake and you’re gone. A compacter or validator might be good. No; too many dependencies. A current backup is essential.
This is my 5000th post, and I’ve been reviewing my previous milestones at 2000 (when I really started openLuup development) and 3000 (when it was beginning to mature.) I see that my post rate has dropped significantly since then, partly because of the fact that most of the functionality originally missing from the implementation has been filled in.
All thanks to those stalwart users (you know who you are) who have berated me on the gaps and enthusiastically tested the incremental code updates (often to destruction!) However, special thanks is due, as ever, to @amg0 who has often gone out of his way to code bespoke functionality in AltUI to support openLuup and get around some of the constraints it imposes. This is very, very much appreciated because, as I noted in my 2000th post, openLuup would be nothing without an interface.
Whilst it’s been difficult to stick faithfully to Vera’s way of doing things when it’s seemed to me that there are better ways, I’ve tried not to diverge too much and then only when I’ve felt there really was something missing (there is a lul_device variable, but was no lul_scene one), or something very poorly designed (like triggers.) There are certainly still quirks and opportunities for development so I’d welcome further suggestions for improvements.
[quote=“akbooer, post:113, topic:189405”]This is my 5000th post, and I’ve been reviewing my previous milestones at 2000 (when I really started openLuup development) and 3000 (when it was beginning to mature.) I see that my post rate has dropped significantly since then, partly because of the fact that most of the functionality originally missing from the implementation has been filled in.
All thanks to those stalwart users (you know who you are) who have berated me on the gaps and enthusiastically tested the incremental code updates (often to destruction!) However, special thanks is due, as ever, to @amg0 who has often gone out of his way to code bespoke functionality in AltUI to support openLuup and get around some of the constraints it imposes. This is very, very much appreciated because, as I noted in my 2000th post, openLuup would be nothing without an interface.
Whilst it’s been difficult to stick faithfully to Vera’s way of doing things when it’s seemed to me that there are better ways, I’ve tried not to diverge too much and then only when I’ve felt there really was something missing (there is a lul_device variable, but was no lul_scene one), or something very poorly designed (like triggers.) There are certainly still quirks and opportunities for development so I’d welcome further suggestions for improvements.[/quote]
Congrats for the 5000s post !
Little feature request, could be nice to have an option to enable “split log” . Instead of having a single log with everything, using split log option, we can have a log PER “plugin/device” ?
