Resolved: The future of Jeenode (puzzled?)

Added by Rolf over 2 years ago

With a lot of pleasure and interest I am following J.-C. Wipplers Weblog about ARM, FPGAs, etc.. - And I would like to share my experience with home monitoring during the last 10 years, perhaps for discussion about what is coming and what we need. I started with an old Laptop and an ancient rs232c-datalogger, at least 6 different platforms lead to that what I have now. Let's omit the details of the history, I am familiar with Linux on routers, raspberrypi and lookalikes, arduinos and jeenodes. - The crucial progress for me was the jeenode, just because (but not only) of the radio interface. No more cables, a few GPIOs per node are enough. If the home network needs to be extended, put another node with some sensors and/or switches. And for many cases the power of a jeenode micro is sufficient.

My conclusion are 2 points. First, with the jeelabs concept of radio communication, I do not need powerful processors (except the central manager), just a lot of (Atmel)jeenodes. Second, though I appreciate the ARM-architecture, I do not need the power in a network node. Except in the central manager, which runs on Linux and perhaps the very low power versions with battery power supply, J.-C. gave examples in his weblog.

What do you think about that (am I old fashioned, progressive or just boring?)?

Replies (5)

RE: The future of Jeenode (puzzled?) - Added by JohnO over 2 years ago

The blog is I suppose a chronicle of one man's journey. Certainly for me also it was the radio and remote sensors that pulled me into the fold and remains my key interest. The sojourn into FPGA, retro computing, and Forth I find interesting and who can tell what is around the next corner. Observing a journey and sharing a few footsteps involves a lot less work and breaks the ground that I would find out of my reach. Perhaps unfortunately, sharing part of a journey doesn't as a right give one access to the reins.

RE: The future of Jeenode (puzzled?) - Added by martynj over 2 years ago

I do not need the power in a network node

IMHO there are at least two aspects here - low power in terms of energy used is key to battery longevity. Modern ARM implementations can be lower consumption that the ATMega family. The computing power? In a sense, the impressive capabilities can sometimes get the job done faster (so less coulombs eaten), but I think this power comes into play when the sensor node is doing more "work" than typically done today. For example, if an a/c current needs sampling accurately, that takes a high speed A/D, signal processing to extract the parameters of interest effectvely providing some compression so that the payload sent to "Central" is a reasonable size.
Another avenue is where the sensor node logic is fairly static and its behaviour is controlled by remote commands from "Central" - the over-the-air traffic is reduced at the expense of running some sort of command interpreter in the sensor node. This would move node configuration up to another level - no code/compile/load cycle (which many are reluctant to deal with) but rather an occasional "command packet" (with some intuitive front end) from "Central". Then the extra MIPS/memory space is not wasted at all.

RE: The future of Jeenode (puzzled?) - Added by NdK about 2 years ago

Well, I'm on the other side: I prefer distributed logic.
That's why I'm creating a mixed unicast-multicast protocol, so every node can accept direct commands and send answers (unicast) but also multicasts its state changes so other nodes can act accordingly (this last part is the one that's giving me some troubles... it's not easy to create a fast&compact parser that's versatile enough).
This way, there's no "single point of failure" (err... actually I'm using ESP8266s so the SPOF is the AP, but that can easily be replaced or made redundant, and the protocol can easily use any other medium instead of WiFi as long as there's something like an IP stack supporting UDP).
A coordinator node is not required, but can be used.
The same for a gateway to "expose" the system to Internet: the protocol is not suitable for Internet, just a local network (but some security is built in: even a local network cannot be completely trusted) and the gateway have to implement all the strong security measures in addition to protocol conversions (MQTT, https API, JSON, etc) to interface to external services.
The key concept I based my design on is "graceful degradation". If two nodes are active and can talk to the AP, they must be able to operate. They must not rely on a coordinator, on the presence of an Internet connection or even a cloud service! These things can be useful for "extras", but I never understood why my button press to turn on a light have to go to a 3rd party server and from there return to my house where another node receives the command to turn on the light (that's what happens if you use Itead's Sonoff).

RE: The future of Jeenode (puzzled?) - Added by jcw about 2 years ago

One doesn't exclude the other, IMO: central data collection and point-to-point control. So far, I've only been looking into data collection, because I'm not (yet?) interested in controlling devices in the house. We'll see...

RE: Resolved: The future of Jeenode (puzzled?) - Added by Rolf about 2 years ago

By the way, everybody has noticed, my entrance question ("the future of Jeenode") has been answered meanwhile.

Concerning a distributed node network, I am thinking about this for some time already, with Jeenodes, RF12(RF69) and a protocol without central instance. The reason why I did not put it into reality is a lack of application. My applications are similar to JCWs, monitoring a house, not just for fun, but to see if the central heating is working, when I am a 2000 kms apart (e.g.) or switching on the heating in the summer house 3 days before we go there in the winter, to prevent getting a cold. This is all very well done with a central instance connected to the internet. And concerning "house-control" from a distance, I decided to rely on trustworthy neighbours more then on technique.