Yep - that works!
a default would be good.
Cheers
@Weeves, it just opens the file in the current directory. Since the current directory is set to “/” by default, it doesn’t find the file if it’s in a subdirectory.
You can change the directory by running [tt]lfs.chdir(‘/etc/cmh-ludl’)[/tt] (or whatever value you need) from the Console when debugging is in progress. This should set it until luup is restarted. You can then open a file using just the file name. I just tested it and it works. In fact, you can probably add it to the startup script if you want.
Also, I’ve been thinking about adding “remote:” indicator to the tab name. Do you think it would be useful?
Glad to see that this is taking off.
Thanks for letting me be a beta tester. It is a pretty cool program. While lately I’ve been occupied with work and a few other things, when I get a chance to put more time back into HA, I will be using this to push forward with my mods to the plugins I’ve done.
I just thought I’d throw some positive feedback out there. I’m not affiliated with the author of this software, but went ahead and purchased a copy of the Vera edition after playing around with the non-Vera integrated version for a few weeks. I had recently posed a question about intercepting http requests initiated outside of the Vera in the MiCasaVerde forum and was pointed toward using lug_WapRequest. I tried some code in ZeroBrane Studio for Vera and at first did not have success, but then posed a question to the ZeroBrane support team. They quickly responded and pointed out the minor change I needed to make. I was able to debug my code fairly quickly. I also used it to debug some luup.variable_watch commands and the IDE allowed me to intercept the events. I’m quite impressed that these work and look forward to spending more time in this IDE!
@hifs, @SOlivas, thank you for the feedback!
I had recently posed a question about intercepting http requests initiated outside of the Vera in the MiCasaVerde forum and was pointed toward using lug_WapRequest.
I updated the documentation with some examples of how debugging works for plugin “startup” code and request (register_handler) callbacks: Documentation - ZeroBrane Studio for Vera/MCV devices - Lua IDE/editor/debugger for Windows, Mac OSX, and Linux. I’m also adding other sections and will update when they are posted.
Using the Zerobrane Output window when remote debugging.
I have a long running Vera process which, when testing, I write messages to the Vera log for later review. This is not ideal because there are a lot of other messages going to the Vera log so it is necessary to copy this file and filter it to see all my messages contiguously, and the size of the log in Vera can be a problem and cause instability. I would prefer to use Zerobrane for this debugging to make use of the pretty print facility in conjunction with the Output window. Is it possible to configure Zerobrane to also write text written to the Output window to a file on the system where Zerobrane is running. This would avoid the issues around using the Vera log. I can then start a Zerobrane remote debug session, leave it running and later, review the captured file.
I would prefer to use Zerobrane for this debugging to make use of the pretty print facility in conjunction with the Output window. Is it possible to configure Zerobrane to also write text written to the Output window to a file on the system where Zerobrane is running. This would avoid the issues around using the Vera log. I can then start a Zerobrane remote debug session, leave it running and later, review the captured file.
@twostep, this is a very interesting idea! I put together a simple plugin to test this functionality: Saving debugging output to a file - ZeroBrane. It will write to output.log file in the current project directory, but you can change that in the config file. It will also “trim” the output to the last 100 lines in the Output window, so you can run long sessions without using much memory.
All the writes to the log file are flushed immediately, so you can check the file while the process is still running. Please let me know if you run into any issues with it.
Not wishing to minimize the advantages of ZeroBrane Studio, you could also just write your logs to a text file in Vera with something like:
local value = 123
local time = os.date()
local file = io.open("/www/log.txt", "a")
file:write("Log " .. time .. " Value: " .. value .. "\n")
file:close()
You can review the results in your browser through /log.txt
RexBeckett, I’m sure there are good alternatives ;); thank you for providing one.
I think two main advantages of using remote printing in ZBS are that the output is pretty-printed (with tables expanded in the output) and it doesn’t require code changes in your scripts (assuming you do “printing” anyway). Also, since the log is already stored locally, you can simply delete the file between sessions if you want to truncate it.
The advantage of your method is that you don’t need any additional tools to collect this in a log file.
One of the problems I have found with logging on Vera is that if significant amounts of logging occurs, Vera can become unstable. Using a separate local log for minimal runtime logging is much better to isolate it from the Vera log but in actual debugging sessions, getting the data back on the client is a good option for me. Horses for courses I guess. It’s good to have the choice.
[quote=“paulclinger, post:14, topic:178001”]> Good job, @paulclinger, this works really well.
@RexBeckett, thank you for the feedback![/quote]
Tried the tutorial (local sunset = luup …) but things are not working as expected.
Output:
Trying to detect Vera device address from mios.com...
Debugger server started at Moncrino:8172.
Connecting to Vera device at 192.168.20.13:3480...
Program starting as '"C:\Programs\ZeroBraneStudioForVera\bin\lua.exe" -e "loadstring(require('mime').unb64('G0xKAQCmBGxvY2FsIHMgPSByZXF... '))()"'.
Program 'lua.exe' started in 'C:\Users\Bernhard Boser\Documents\Files\Personal\Automation\Vera\plugins' (pid: 1168).
Program completed in 189.65 seconds (pid: 1168).
Now way to pause or stop the program either. Just sits there, and when I already thought it was broken, it suddenly decided it was finished now. Same problem with a print statement only.
What’s wrong?
Now way to pause or stop the program either. Just sits there, and when I already thought it was broken, it suddenly decided it was finished now. Same problem with a print statement only.
@ttmetro, Thank you for the report. It seems like the IDE doesn’t receive the debugging request from the device. It may happen for several reasons:
-
You have a firewall that blocks incoming connections to port 8172.
-
The IDE incorrectly detected the hostname, which is then given to the application that will connect to the IDE to start debugging. IN your case the hostname is shown as “Moncrino” (Debugger server started at Moncrino:8172.), but it’s possible that this address doesn’t resolve when used from the device. You can configure the hostname to use instead of auto-detected one by going to “Edit | Preferences | Settings: System” and adding
debugger.hostname = ‘ip-address-of-PC-with-IDE’
Save the file and restart ZBS and then try starting the debugging again.
- If nothing else works, it’s possible that the debugger component was not correctly set on the device. You can reset the saved configuration and try to set the debugger again, which may resolve this issue. Run the following command from the Local console in ZBS (just replace 35…22 with the full number of your device):
(function() local s = ide.packages.vera:GetSettings(); s[‘35…22’] = nil; ide.packages.vera:SetSettings(s) end)()
You can then try the debugging again. Please let me know if one of these steps resolves the issue. I’ll update the troubleshooting section in the documentation. Thank you. Paul.
doesn’t connect to Vera:
Trying to detect Vera device address from mios.com…
Debugger server started at xxxxxxx:8172.
Connecting to Vera device at 192.168.1.101:3480…
Failed to connect to Vera device after 3 seconds.
It didn’t prompt for the key.
Connecting to Vera device at 192.168.1.101:3480…
@persimmonx, was the address of the device detected correctly (192.168.1.101)? Can you ping that address from the computer running ZBS? At this point the IDE will attempt to contact the unit using this URL (http://192.168.1.101/cgi-bin/cmh/online_check.sh?tmp=1) and will report failure after 3s if the unit doesn’t respond. You can test that URL manually and if everything works, just start the debugging again from the IDE.
It didn’t prompt for the key.
It would be the next step after the unit is detected.
yes 192.168.1.101 is the address of my Vera. I ssh to Vera from the computer I am running ZBS from.
The URL you send works correctly and returns: test({“PK_AccessPoint”:“30004165”});
But still IDE gives the same message and doesn’t connect!
yes 192.168.1.101 is the address of my Vera. I ssh to Vera from the computer I am running ZBS from.
The URL you send works correctly and returns: test({“PK_AccessPoint”:“30004165”});
But still IDE gives the same message and doesn’t connect!
That’s interesting. My apologies for the inconvenience.
Can you try running the following two commands in the Local console of ZBS:
package.path = package.path…‘;’…MergeFullPath(ide.editorFilename,‘…/lualibs/?.lua’)
require(‘socket.http’).request(‘http://192.168.1.101/cgi-bin/cmh/online_check.sh?tmp=1’):match('“PK_AccessPoint”:“(.+)”’)
Also, what OS are you running this on?
debugger.hostname = ‘ip-address-of-PC-with-IDE’
I need to correct myself; the Vera component will overwrite “debugger.hostname” value with the IP address it detects based on the result of following code: “socket.dns and socket.dns.toip(socket.dns.gethostname())”. Can you run it in the Local console of ZBS to see what it returns:
socket.dns and socket.dns.toip(socket.dns.gethostname())
It should return the IP address of the computer running the IDE, but depending on your network configuration it may pick the wrong address.
[quote=“paulclinger, post:32, topic:178001”]> Now way to pause or stop the program either. Just sits there, and when I already thought it was broken, it suddenly decided it was finished now. Same problem with a print statement only.
@ttmetro, Thank you for the report. It seems like the IDE doesn’t receive the debugging request from the device. It may happen for several reasons:
- You have a firewall that blocks incoming connections to port 8172.[/quote]
Firewall was the problem.
socket.dns and socket.dns.toip(socket.dns.gethostname())
does return the IP address of the local host.
Thanks,
Bernhard
Firewall was the problem.
socket.dns and socket.dns.toip(socket.dns.gethostname())
does return the IP address of the local host.
Bernhard, so are you up and running after the firewall change? Please let me know if I can help with anything else.
Paul.
Yes, after opening the firewall it’s working fine now!
Many thanks!