LevelDB is also so compact, performant, and scalable, that HouseMon can now store all raw data as well as a complete set of aggregated per-hour values without running into resource limits, even on a Raspberry Pi. At this point, you just start up Node.js and everything will work.īut it’s not just convenience. run “npm install” to get everything needed by HouseMonĪnd that’s it.install Node (which includes the “npm” package manager).download a recent version of HouseMon from GitHub.This means that there is no need for a separate process to run alongside Node.js – and hence to need to install anything, or keep a background daemon running.īy switching to LevelDB, the HouseMon installation procedure has been simplified to: One reason for me to select LevelDB for HouseMon, is that it’s an in-process embedded database. Redis, LevelDB, and MQTT all support pub-sub in some form. The main difference with LevelDB, is that Redis is memory-based, with periodic snapshots to disk, whereas LevelDB is disk based, with caching in memory (and thus able to handle datasets which far exceed available RAM). It’s also interesting to compare this with the Redis database: Redis is another key-value store, but with more data structure options. This makes LevelDB and MQTT functionally equivalent, although LevelDB can handle much larger key spaces (note also that MQTT has features which LevelDB lacks, such as QoS). a database with change tracking, but the effect is exactly the same: you can subscribe to a set of keys, get all their latest values and be notified from that point on whenever any keys in this range changes. This can be very convenient after power-up as well. With RETAIN, the MQTT system becomes a little database, with one value per channel. This turns an ephemeral message-based setup into a state-based mechanism with change propagation, because you can subscribe to a channel after devices have published new values on it, yet still see what the best known value for that channel is, currently. One interesting aspect of MQTT is its “RETAIN” functionality: for each channel, the last value can be retained, meaning that anyone subscribing to a channel will immediately be sent the last retained value, as if it just happened. Other devices or software can subscribe to such channels, and get notified each time a value is published. “/location/device/sensor”, to which one can publish measurement values (“publish /kitchen/roomnode/temp 17”). There are channels, named in a hierarchical manner, e.g. This is an area where the “Message Queue Telemetry Transport” MQTT has been gaining a lot of attention for things like home automation and the “Internet of Things” IoT. One particularly interesting aspect is the “persistent pub-sub” model you can implement with this. Together, all these features and conventions end up playing together very nicely. Individual cases can still override these defaults. The latter means that the default “stuff” stored in the database is simply a JavaScript object, and this is also what you get back on access and traversal. In the case of HouseMon, I’m using UTF-8 as key encoding default and JSON as value encoding. Standard encoding conventions can be defined for keys and or values. This is really nothing other than publish / subscribe, but again in a form which matches Node’s asynchronous design really well. These can easily be translated into a “live stream” of changes. This is a very nice match for Node.js and for interfaces which need to be sent across the network (including to/from browsers).Įvents are generated for each change to the database. traversing a set of entries for reading, as well as sending an entire set of PUTs and/or DELs as a stream of requests. The levelup wrapper for Node supports streaming, i.e. To follow up on yesterday’s post, here are some more interesting properties of LevelDB, in the context of Node.js and HouseMon:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |