Node.js module to talk to the gateway
-
Long time lurker, first time poster.
I've implemented a node.js module which you can include in your node projects, that does the dirty work of communicating with the serial gateway, and exposes a (hopefully) simple API to interact with your mysensors network.
Find the project on Github or NPM.
I've tried this with a Serial gateway, and it works fine. I haven't been able to test it with a Ethernet / WiFi gateway, but it should work fine with them as well.
Please feel free to use this in your code, if you like, and let me know if you have any suggestions/feedback (or post an issue on Github).
-
Welcome to the community @rakeshpai Nice when lurkers reveal themselves with a bit of code.
-
Nice work, I will look for a such solution.
-
Hi! Thank you for the contribution! I'm starting to learn Node.js and it looks like your code is great one as a starting point
-
@hek, @Fabien Thanks! When writing this module, I faced an issue that is probably worth bringing up. Details follow. Let me know if I'm doing it wrong.
It appears that a sensor node's presentation data is only published when it is power-cycled. So, if my node.js module (or the app that includes it) has to restart for any reason, it can't figure out what the capabilities of nodes are, unless all nodes in the network are restarted too. To work around this, I've had to store the sensor nodes' presentation information to disk as a file in case the controller restarts. This works for now - it isn't ideal, since all nodes still need to be restarted at least once after the controller is executed the first time. Instead, I'd rather just query the nodes to get their presentation data whenever necessary. That way, not only do I avoid persistence, I also only need to rely on one source for the data - the sensor node itself - eliminating a large class of bugs due to data going out of sync with respect to the persisted config file.
Some more details: Right now, my module has to do some trickery to persist data to disk, which involves an in-memory cache, and a timer to flush to disk. (This is necessary since presentation data can involve multiple packets, and issuing a FS write on every packet seems excessive, so some buffering seems appropriate.) To hide this behind the module's abstraction, the module does all the FS operations at a path that it deems appropriate, which is an uncomfortable choice. The module could ask the developer to specify a path for persistence, but that's yet another thing that developers have to do when using this module, with only a hard-to-communicate benefit, and that increases friction. Because we are dealing with the file system, the module also has to handle differences between Windows and Linux paths for cross-platform compatibility. Also, it isn't possible for two different apps to use the same module for the same network since data can get out of sync (the config is local to the app), unless the config files are stored in a shared location, which opens another can of worms (FS watchers or some form of IPC would be required, for example.). I could have avoided this FS jiggery-pokery by taking a dependency on a DB - the official NodeJsController, for example, requires mongodb - but that's an additional thing in the stack that needs to be up-and-running for the module to work, and requires additional configuration in the code to communicate with the DB anyway. The FS operations seem like a milder issue in comparison, in the usually-works-in-the-common-cases sense, but it would be great if I could avoid it altogether. After all, the sensor node knows its presentation, so it's much more authoritative to simply ask the node itself.
I hope all that made sense, and I haven't overstated the problem. A solution in my mind would be to REQ a node for its presentation data when needed, and the node could RES with its presentation. The docs don't say that this is possible, but my reading of the source IIRC tells me that might be coming in v2.0. Is that right? If not, is this something we can consider for future releases? (I would have contributed, but my C/C++ is very weak.)
@danylevskyi. Thanks. Not sure i can deal with the pressure, though.
-
In 2.0 beta, you can query the node by sending INTERNAL/PRESENT message to it. But it will only work for awake nodes that is listening.
-
@hek Thanks! That's neat! I'm not sure about this - is it possible to ask a node for its presentation, just when I receive data from it? Will it be awake?
For example, if a sensor says that its state is 'triggered', and is expected to sleep right afterwards, do I still have time to ask it for its presentation data? Is the sensor going to wait for an INTERNAL request? If not, what is the best time to ask for data?
-
Yes, if node uses "smart sleep"
-
Hello,
I did made one in perl for my experiments:
https://github.com/empierre/domoticz/blob/master/mysensors-gw1.4.pl
If you are interested in having an interface to Imperihome, or just for continuous test/delivery/packaging for all PI and more on node JS, I can help (this is the project taking me time at the moment, full rewrite from perl to node js of an app used by more than 100 people):
