So, my webthing is working, more or less…
Next on my agenda is the gateway adapter.
Following templates provided on github I have something to start from.
My question is more about development environment.
Can anyone suggest a good environment to work with??, with possibilities to step, trace and debug the code.
I have used VS Code and the PlatformIO plugin for Webthing development. It would be nice using something similar.
If you’re just trying to get your web thing to work with the gateway, you don’t need to create an adapter. Instead, you’ll just use thing-url-adapter (Web Thing).
If you still want to create an adapter for some other reason, this guide would be a good starting point.
Yes, it is a good article, but it is not telling me anything about the development environment. Developing my device based on a ESP8266 was very much trial and error and hundreds of Serial.prinln(“xx”);
I really would like to have better environment with the possibility to set breakpoints, trace code etc.
So, I need some direction in that area…
That depends on what language you’re writing your adapter in. You’d have to use the respective dev tools for the language you’re using.
I am planning to use javascript and vscode.
Then you can use normal debugging tools for node. See https://nodejs.org/api/debugger.html (and yes, the fancy interface requires you to use the chrome dev tools 
though I think you can use the ones that come with electron in vscode iirc). You’d need to have the gateway running locally on your dev machine and adjust the launch command for your adapter to allow debugging the node process.
Okay,
I am trying to setup a environment according to this instruction https://github.com/mozilla-iot/gateway
On a HyperV server I have a Windows 10 client running.
I have installed nanomsg for 64 bit system.
then I followed this steps:
> git clone https://github.com/neutrinoyu/nnpy-win.git
> mv nnpy-wi nnpy
> cd nnpy
> python3 -m pip install .
Please not I am using nnpy-win instead of nnpy beacause nnpy gave me other errors and according to google this should fix it.
But, nnpy-win caused the following error:
Processing c:\program files\nnpy
Complete output from command python setup.py egg_info:
warning: no previously-included files found matching 'setup.pyc'
warning: no previously-included files matching 'yacctab.*' found under directory 'tests'
warning: no previously-included files matching 'lextab.*' found under directory 'tests'
warning: no previously-included files matching 'yacctab.*' found under directory 'examples'
warning: no previously-included files matching 'lextab.*' found under directory 'examples'
zip_safe flag not set; analyzing archive contents...
pycparser.ply.__pycache__.lex.cpython-37: module references __file__
pycparser.ply.__pycache__.lex.cpython-37: module MAY be using inspect.getsourcefile
pycparser.ply.__pycache__.yacc.cpython-37: module references __file__
pycparser.ply.__pycache__.yacc.cpython-37: module MAY be using inspect.getsourcefile
pycparser.ply.__pycache__.yacc.cpython-37: module MAY be using inspect.stack
pycparser.ply.__pycache__.ygen.cpython-37: module references __file__
Installed c:\users\lars-g~1\appdata\local\temp\pip-req-build-vsvub3fh\.eggs\pycparser-2.19-py3.7.egg
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "C:\Users\LARS-G~1\AppData\Local\Temp\pip-req-build-vsvub3fh\setup.py", line 28, in <module>
install_requires=['cffi'],
File "C:\Program Files\Python37\lib\site-packages\setuptools\__init__.py", line 143, in setup
return distutils.core.setup(**attrs)
File "C:\Program Files\Python37\lib\distutils\core.py", line 108, in setup
_setup_distribution = dist = klass(attrs)
File "C:\Program Files\Python37\lib\site-packages\setuptools\dist.py", line 442, in __init__
k: v for k, v in attrs.items()
File "C:\Program Files\Python37\lib\distutils\dist.py", line 292, in __init__
self.finalize_options()
File "C:\Program Files\Python37\lib\site-packages\setuptools\dist.py", line 601, in finalize_options
ep.load()(self, ep.name, value)
File "c:\users\lars-g~1\appdata\local\temp\pip-req-build-vsvub3fh\.eggs\cffi-1.11.5-py3.7-win-amd64.egg\cffi\setuptools_ext.py", line 204, in cffi_modules
add_cffi_module(dist, cffi_module)
File "c:\users\lars-g~1\appdata\local\temp\pip-req-build-vsvub3fh\.eggs\cffi-1.11.5-py3.7-win-amd64.egg\cffi\setuptools_ext.py", line 49, in add_cffi_module
execfile(build_file_name, mod_vars)
File "c:\users\lars-g~1\appdata\local\temp\pip-req-build-vsvub3fh\.eggs\cffi-1.11.5-py3.7-win-amd64.egg\cffi\setuptools_ext.py", line 25, in execfile
exec(code, glob, glob)
File "generate.py", line 133, in <module>
ffi = create_module()
File "generate.py", line 126, in create_module
library_dirs = [DEFAULT_LIBRARY_DIR], libraries=['nanomsg'], **set_source_args)
TypeError: set_source() got multiple values for keyword argument 'library_dirs'
----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in C:\Users\LARS-G~1\AppData\Local\Temp\pi
Can anyone help me out here. I’ve reported on the nnyp github site, but so far no response.
I really would like to have some good ideas for solving this, I am stuck…
I’m using a bit of a different approach, developing the addon locally and then pushing it to my Raspberry Pi running the Things Gateway with a script that runs debug mode and outputs the running log. I haven’t yet tried attaching the node debugger but I notice that the gateway already has an npm script defined for debug mode (npm run debug) which should then allow the debugger to connect.
It helps to have all other addons disabled when developing an addon this way, so you mostly just see your own addon’s debug output.
Here’s the repo to the addon I’m currently working on: https://github.com/cr0ybot/almond-adapter
There are 2 files of interest to you: run.sh and debug.sh. The run script handles syncing the files to the rpi into the appropriate addon folder, and then remotely running the debug script on the rpi.
The run script assumes that you’re using a Raspberry Pi flashed with the official gateway image to run the things gateway.
If you need the debugger, try changing the last line of debug.sh from npm start -- -d to npm run debug -- -d. I’m going to try this when I get a chance and report back.
EDIT: I’ve confirmed that using npm run debug -- -d works, but I didn’t test connecting the debugger.
EDIT 2: Remote debugging with Chrome devTools doesn’t appear to work unless the debug script in the gateway’s package.json is changed from webpack && node --inspect build/gateway.js to webpack && node --inspect=0.0.0.0:9229 build/gateway.js (see https://github.com/nodejs/node/issues/11591). If you change that, Chrome can connect at chrome-devtools://devtools/bundled/js_app.html?experiments=true&v8only=true&ws=%IP_ADDRESS%:9229/%UUID%—where %IP_ADDRESS% is the local IP (gateway.local won’t work) and %UUID% is the unique string output in the console right before the gateway script starts (line looks like: Debugger listening on ws://0.0.0.0:9229/5d420195-df70-4f22-bafc-5c1294b45455).
EDIT 3: OK, last edit I swear. Instead of changing the gateway’s package.json, I instead tried running webpack & the gateway directly by replacing npm run debug -- -d in debug.sh with node node_modules/webpack/bin/webpack.js && node --inspect=0.0.0.0:9229 build/gateway.js. This isn’t really ideal either because the commands to run the gateway might change in future versions, but it does work. However, none of this seems worth it when I’m getting the same exact output in my terminal and I can’t seem to find the addon to do breakpoints and whatnot.
Interesting setup with at least one big advantage. I have a Zigbee usb stick and in your suggestion I can use that i raspberry pi.
I have setup VSCode with the following configuration:
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Attach to Gateway.local",
"address": "XX.XX.XX.XX",
"port": "9229",
}
]
I used your debug.sh to start gateway in debug mode.
npm run debug -- -d
But, when starting VsCode with configuration, according above, I get the following error from VsCode.
Cannot connect to runtime process, timeout after 1000ms .... ECONNREFUSED ..
Any idea ???
Have you succeeded in connecting the debugger to gateway.local ?
Yes, I was able to connect the debugger, see Edit #2. The only way to do it is to start the gateway process using --inspect=0.0.0.0:9229, which requires either editing the gateway’s package.json (which resides on the rpi at /home/pi/mozilla-iot/gateway/package.json), or editing the debug.sh script like I did in Edit #3.
Okay, I tried those but no luck…
How is your VSCode configuration looking ??
Okay, I got your Edit3 to “work”, don’t know how to set breakpoints although.
Yea, unfortunately, I couldn’t figure out breakpoints either. Also, apologies if I wasn’t clear that I’m not using VSCode, just Chrome’s nodejs debugger.
Maybe one of the Mozilla folk could chime in about this setup? Are we just doing this in a silly convoluted way? Would it be feasible to have --inspect=0.0.0.0:9229 as an option when debugging the gateway? (See Edit 2 above.)
I found this addon to VsCode: Remote Workspace
I’ve installed and configured.
VsCode are showing the complete gateway directory like I was running on Raspberry pi.
I can use all npm commands and scripts including starting the gateway.
I can see all gateway code and set breakpoints using VSCode, but how to start the debugger ?? 
Just a quick note for anyone trying this after today, version 0.7.0 of the gateway was released today and my debug script stopped working because it looks like the devDependencies of the gateway weren’t included in the update. Which makes sense, of course, but throws a bit of a wrench in things when npm start -- -d, the documented way of debugging the gateway, doesn’t work anymore.
The reason this doesn’t work is because the npm start script includes an invocation of webpack, which is a devDependency. Now you could fix this by installing the devDependencies: cd into the gateway folder (~/mozilla-iot/gateway), run npm install, and prepare to be very patient because it takes a really long time. I thought it was going to choke on the sqlite install but it finally pushed through after sitting for a few minutes.
However, its much more expedient to just use npm run run-only -- -d which just starts the node program and also outputs the debug log without re-packaging the entire gateway. This is much faster.
@lg.lindstrom I don’t think you’re going to accomplish utilizing breakpoints that way, it sounds like the plugin you installed is basically just an embedded ssh terminal.
We use travis to build the gateway and dependencies. It sounds like having an option to build the gateway WITH devDependencies is desirable. I should be able to add that fairly easily.
Currently, anybody with a github account should be able to trigger a build. You need to checkout the https://github.com/mozilla-iot/rpi-image-builder repository and run the trigger.sh script.
This will require having the travis command line tool installed, which can be done by following these instructions: https://github.com/travis-ci/travis.rb#installation
I found I had to install ruby-dev in addition to installing ruby.
./trigger-build.sh --branch master --prefix my-prefix
You can then monitor the build at https://travis-ci.org/mozilla-iot/rpi-image-builder it will print out a couple of http URL at the end of the log where you’ll be able to download the results.
Currently we only do production builds, but I’ll add an option to the trigger-build.sh script so that it can do dev builds.
You can now pass in --dev to trigger-build.sh and the gateway tarball that is produced will contain the devDependencies
@cr0ybot : Well, it sounded to good to be true,
@dhylands: Can you tell us how your development environment is set up. I’ve seen that you have contributed ( or written ) the Zigbee adapter, and I assume you not are debugging by writing log messages
Yes - I actually develop by using logging messages. I’ve never actually used the node debugger. I find that debugging this type of activity goes much faster using log messages rather than the debugger since the time that you’re paused in the debugger typically messes things up. Which is the problem with debugging realtime type things in general.
My development environment is that I run the gateway on my linux development machine and I have dynamic debug logging that I can turn on/off.
Debuggers have a time and place and I do use them when appropriate.