filar

I have been here a lot longer than that, and I do recognize some of these comments coming from long-time PJON users parttaking in the PJON gitter channel, asking for advice from other users, asking for new features, etc.

What is wrong with users of an open-source library commenting on the library? Who is better qualified to comment, and what is to be gained -- it is open source, free for all?

I have used PJON, with the SWBB and DUDP strategies, for my home automation setup for at least 4 years. I do not need the kilometer range of SWBB, but have stretches of tens of meters running alongside 220V AC wires with no problems, in both star and daisy-chained topologies. The system is very stable, and I would like to point out that the alternatives I looked at before required me to buy extra hardware/shields that cost more than the Arduinos themselves to get going. With PJON it is just connecting to the pins in the most inexpensive way. This plus multimaster, the strength against interference, the long cable lengths and few topology limitations makes it a clear choice for many purposes. Plus, it is free :-)

Small correction: Using CRC is not optional. Setting the crc flag makes it use CRC32 even for very small packets. The default is to use CRC8 for packets of a few bytes and then upgrade to CRC32 over a small size threshold. This is to minimize the size of otherwise tiny packets.

Also, the ACK implementation depends on the strategy (physical media type), and it is not a single bit but a single byte, and it seems to me to be robust. I am sure the creator, gioblu, has some more comments about this.

PJON is based on a concept of selectable "strategies" to support using the protocol with different physical media. Some of these, like the one named SoftwareBitBang which allows a bus on a wire connected directly to an I/O pin, are very compact.

There are also strategies for TCP and UDP based communication, essentially using the same packet structure but sending them as TCP or UDP over a LAN or WAN. These strategies need the Ethernet library, and use more memory.

Still, the memory requirement is small enough to run a router with two PJON objects with the strategies SoftwareBitBang and DualUDP on an Arduino Nano with a W5500 Ethernet shield. This allows easy traversal between different physical media, and IP-based communication, also with PJON-based software running on a Windows or Linux computer.

Although not using PJON addresses as IP addresses, PJON has a few strategies that allow a PJON bus to span a Ethernet+WiFi LAN and/or WAN. I use this in my PJON-based home automation system using clusters of SoftwareBitBang based devices (a bus on a single wire plus ground), linking these clusters together and with the master with routers using the DualUDP strategy over my LAN. PJON is great for cases like this.

It could easily cross the Internet as well but in that case I would recommend using site-to-site VPN commections for security as the PJON traffic is not encrypted (encryption is a little too heavy when running on limited devices like Arduino).

I have shared my PJON-based automation library here for those interested: https://github.com/fredilarsen/ModuleInterface

Every user of Arduino and similar devices who do not know PJON should take a look. Especially the SoftwareBitBang strategy is genious, allowing lots of devices to communicate over a single wire (plus ground) over long distances on a bus, without wasting money and space on communication shields.

I use PJON as a basis for a library I created for my home automation, and it works flawlessly (https://github.com/fredilarsen/ModuleInterface).

Also check out the related ModuleInterface library (https://github.com/fredilarsen/ModuleInterface) that lets devices declare their contracts for settings, outputs and inputs and a master that synchronizes these between modules and to and from a web server / database.

It does data logging and storage to a database for trending and/or analysis, as well as configuration in a web page.

It uses PJON as transport, so it can run on one or multiple of the supported media, for example a SoftwareBitBang bus between worker devices, with a router that connects them via UDP to a master process on Linux. Or any other combination.