Ethernet --> cellular with RPi and Electron?

I have a device that I’m currently interfacing to with a Photon. However, WiFi/Internet at the site is not reliable and I’m thinking of going cellular. The device has an Ethernet port, so I’m thinking of using a Raspberry Pi to connect to the device and then use serial communications with an Electron to get the data pushed to the cloud. Does this make sense or is there a more elegant solution? I guess an alternative would be to use a Photon and keep the WiFi-Ethernet router in play, but it means an additional device.

I do recall a thread (but can’t quite find it now) where a member got his Photon to the RPi’s WiFi hotspot - if this was an option.

I’ll look some more for that. The device I need to pull data from has an Ethernet interface…hence the thought of the RPi.

What you are proposing makes sense. How are you currently interfacing the device with the Photon? Over WiFi or some other means?

The device is connected to an ad hoc LAN through a standard WiFi-Ethernet router. So…the Photon communicates via WiFi to the router which passes data to/from the device via Ethernet. The router’s WAN port is connected to the site’s LAN, but their IT department is rather indifferent to the needs of the department that has the device. Therefore, I thought we’d simply bypass them and go cellular to the cloud.

FWIW…using the EasyTransfer library, it was simple to have two Particle devices pass data to one another. I tested passing a char string, as that would be the nature of the data I would need to pass and simply have the Electron do the Particle.publish() in lieu of it happening on the Raspberry Pi. thanks Bill Porter for a handy library!

That makes sense. What is the device? If it had a serial connection it would be super easy to interface with. Otherwise you’ll need something with an ethernet port that can act as a “router”. I imagine the Pi can but I’m not certain.

Glad to hear you like the Easy Transfer library. I hadn’t seen that.

The device is a water quality analyzer by YSI. It has an Ethernet interface that supports Modbus and I’ve written somewhat of a hack to get the data out of it for the parameters that need to be pushed to the cloud. The issue they’ve experienced is an IT organization that has little interest in supporting the department that needs the data logged. There are also other meter readings provided via 4-20mA interfaces that are being pushed as well, but the WiFi is questionable. The Photons that are being used with those meters would also be swapped out with Electrons to completely eliminate the WiFi issue.

The thought it to update the system of 7 Photons to 7 Electrons to completely avoid the local IT infrastructure. Since Particle now supports the Raspberry Pi device via the IDE, I’m thinking of simply replacing the Photon that currently talks to the YSI with a Raspberry Pi that would have a serial connection to an Electron to easily get data to the cloud. Additional development work should be minimal as the Electron would really be just a simple bridge from the Raspberry to the cloud by way of the EasyTransfer library. In essence the Particle.publish() calls would be moved to the Electron and replaced on the Raspberry with EasyTransfer calls to get the data to the Electron.

@ctmorrison, I found the post I was thinking of

Here the RPi is exposing a WiFi AP a Photon can connect to and since the RPi has Ethernet on board, I’d think that could be the way out (if the IT crowd would at least let that happen).

I noticed in another topic that Serial1 is not implemented at this time on RPi and there’s no timeframe for when that might happen. Therefore, since I believe I’ve worked out a solution to the EasyTransfer buffer issue, I’d be wise to use a Photon to talk to the YSI device (via an ad hoc WiFi router) and then have the Photon connected serially to an Electron to push the data to the cloud via cellular.

Am I accurately getting the lay of the land?

I guess you can, but if your solution requires 1200 baud (as seen in the other thread) then I guess there is some room for tuning as that should go a lot faster - even with “cramming” 200+ byte into the 64 byte buffer.

The solution does not require 1200 baud. I simply tested it and it has worked flawlessly for hours now. I guess I could try higher speeds to see when it fails, but I’m perfectly satisfied with 1200 baud if it gives me reliable communications between the two devices.

[update] would not work at 4800 baud, but works fine at 2400 baud. Interesting.