Ray Kholodovsky   Peter van der Walt   Re.

@raykholo +Peter van der Walt

Re. CP/SPJS/MQTT (or other pub/sub protocol I suppose)/ESP8266.

Say you have multiple ESP8266’s connected via MQTT. Have you given any thoughts on how to send commands to a specific device?

Lets say SPJS gets MQTT capabilities (either becomes an MQTT server itself, or connects to an ‘external’ MQTT server). Then MQTT could become a fake serial port (this is what I’m working on). When CP sends to that port, data gets published to the MQTT server.

How then to differantiate between the individual ESP8266’s? Maybe the data would contain an ID that identifies the right ESP8266. And that ID must also be used when an ESP8266 sends data ‘back’…?

So the data sent from CP must contain the topic as well as payload?

Note: I myself are using an adapted (he) version of the topic hierarchy made by IBM for the “MQTT Sensor Fabric”.

What about Service Discovery - any thoughts?

Good morning.
Here’s the operating plan so far: @jlauer wrote the Cayenn protocol which is in SPJS and also consists of a Lua script for running on the NodeMCU/ ESP8266. Very simply put, as soon as the ESP is on wifi, it starts broadcasting over UDP “Hello, I’m here” + ‘guid’ + my IP Address. SPJS sees it and then you get a publish from the Serial Port widget in Chilipeppr itself with that information.

My plan for toolheads specifically: When I was originally testing this I was running a web server on the ESP and using HTTP GET commands to trigger things: for example /gpio/3/on or /servo/1/90. I would not mind keeping that structure in the pubsub data.
As for identifying, each ESP should have a description/ ID that matches up to its corresponding widget. as part of its lua/ arduino code that it broadcasts as part of the discovery process. For example ‘PickNPlace’, ‘SolderDispense’, or ‘ReflowOven’. This has to be standardized enough that it matches the respective widget - that way each widget knows to subscribe to the toolheads that interest it only.

Combine this with the guid and Chilipeppr now has a very solid way to understand "Look, this guid right here is a pick n place toolhead, let me add that reference to my present toolheads array, and then when the Eagle PCB widget says pick n place head 1 rotate 90 degrees we have a macro that directs this to an ESP widget or wherever the reference is stored that “Pick n Place toolhead 1 is at this IP Address, I need to send this call there”

By the way I am getting a “go failed to connect to redis at port 6379” when I try to run gossipd and am still working on getting Mosquitto running on one of several devices so I can start playing around with the ESP8266 side of this.

I’ll echo what Ray has conveyed. In version 1.88 of SPJS the start of the Cayenn protocol was added so CP can talk to IoT devices.

Here’s how the current Cayenn protocol works.

  1. Your device sends out a broadcast UDP packet to something like 192.168.1.255 saying “hey, i’m here and here’s my unique ID” which on an ESP8266 is done using it’s Mac address + Chip ID + Flash ID + IP Addr.

  2. SPJS gets the broadcast packet and makes note of the IP address that sent it in as well as the unique ID. SPJS turns around and broadcasts that to all websockets so CP can see the IoT device.

  3. SPJS sends back a “hey, i’m your server” message via UDP and TCP to the device just so the device knows a server was found so it can stop announcing.

  4. CP gets a message (all CP instances connected at that time) of the device’s existence so a widget can be shown automatically. The widget can then do whatever it needs to for directly connecting to the IoT device such as now using MQTT directly to the device or it can keep slingshotting data via SPJS using the new “cayenn-sendudp” command that was added in the 1.88 version of SPJS.

I do think then adding MQTT to SPJS could be cool so the IoT device now connects back over MQTT to SPJS and SPJS re-broadcasts the pubsub signals to all CP instances.

@raykholo Re. redis: Methink it’s a database server that must be running. I find that’s kinda a bummer for the idea of integrating Gossipd into SPJS. But of course, the broker need something to store persistent messages in…

Awesome, i’ll use this for the XReflow solution. A isolated device that control heatpads via temperature sensor.