It seems there is no choice for a Xenon/Ethernet combo in the create product dialog - any reason why?
Good question. I think that is because Particle haven’t sorted out the product/charging model yet for Xenon only mesh networks where the gateway device is a Xenon using Ethernet LAN. I will raise it at the G3CC tomorrow. Someone from Particle might reply in the meantime.
1 Like
I had that suspicion, however no reason it shouldn’t be similar to a wifi model - hardware cost is more than an argon though.
I ask @will this question today. Probably best if he replies on this thread. My understanding of his explanation was as follows: Originally fleets were comprised of single device types but nowadays Particle are seeing mixed fleets and this is increasingly so with the mesh network devices. The product model with a one to one relationship with device type is therefore being revised with a more flexible concept that will support many device types. In the meantime, a xenon device probably needs to be added. Timescales TBA.
1 Like
Hey there – a bit of background on this constraint from the platform side.
Presently, our construct of “products” are devices of a single platform ID. This constraint was less disruptive for the Photon and Electron because it was extremely rare that customers would build products across Wi-Fi and Cellular connectivity types.
With the introduction of Gen 3 devices, we introduced two instances where it would make sense to create products with multiple platform IDs:
- Mesh deployments, where you have one device acting as a gateway and Xenons acting as endpoints
- Multi-generational products, where you might start with an Electron and migrate to the Boron with a new version of the product
We are currently working to overhaul this architecture to allow for products of multiple platform IDs to exist within a single “product”. It’s a rather large change given how the platform evolved, and an extremely important constraint to relieve for product creators scaling with our platform.
Xenons are not selectable today because of the assumption that any product that contains Xenons would require a network gateway (Argon, Boron), and that products with multiple platform IDs are not yet supported. I see and appreciate that your example disproves that assumption.
I’d love to learn more about what you’re building so that I can have a discussion with the rest of our product team. Would you be willing to share more about your use case?
2 Likes
Hi Will - happy to share. First some background:
We have been creating connected products for 6 years now and have deployed some 7000 devices. The previous product iteration is based on PIC32 with GSM and Ethernet capabilities. The reason for both was to provide redundancy as our target markets generally have some form of life safety implications and thus we need to avoid any single points of failure where psossible (our aggregation and presentation databases are Casandra based and hosted in different AWS zones).
We wanted to use particle from the early days because of the far richer Console and OTA capabilities, however until now there wasn’t a viable way to get the hard wired capability.
Our current project (in final stages of design) is a baseboard/carrier for the mesh devices that has RTC, SD, EXT LiPO and I2C PMIC, 5V I2C external bus, 5V digital I/O (PWM & OneWire capable), SPDT relay, dual power (PoE and 12VDC) in a DIN rail mount enclosure with 0,96" I2C LCD. This will allow a huge range of sensors to be managed in a very versatile package - and most feather compatible MCU’s will also work as the core.
The current use cases are:
-
Monitoring building/control management systems with over 500 sensors and relaying that data to our central system for aggregation, display and alert generation. Controlling the system remotely for specific alarm cases. As this system impacts life safety we need the dual comms path (Eth and GSM) for the buildings where people are present, however in dark sites, we only need the ETH in most cases.
-
Monitoring simple I/O requirements with remote display and alert generation as well as remotely controlling actuators (or the onboard relay) to do things such as remote reset or to actuate based on local sensors (i.e. Heating/Fan based on temperature). Here the simple Xenon & Eth combo is perfect (I could use an Argon with WiFi off, but thats a waste of money)
The application firmware is such that the device will self configure on connection and get its rules of operation each time it starts - so we need a reliable (where possible) wired connection to make sure this happens as expected. Of course extending with mesh will be our next phase as the capability is built in.
I do appreciate that the ETH wing is a late addition and as such does not seem to fit well into the architectural roadmap (i.e. it doesn’t play with other SPI devices like SD and it makes UART2 unusable amongst other things) - so I can see that it is easy to assume only WiFi and GSM are your gateway devices and this is all well and good in the simple interpretation of IoT - but if you want to get into commercial and industrial use cases - wired is always preferred due to stability, predictability and cost effectiveness.
Let me know if you need more info?
2 Likes
I guess you have already considered, but just for the record:
As an additional failsafe measure you could have the last set of fallback rules (updated whenever they changed) saved in EEPROM and/or on SD in case of unreachable internet.
Yes - we have a default set that will be used in these cases, however when any connection is made - any rule difference is overlaid onto the “woking” copy of the rules. There is an on device button to reset to defaults. Currently stored in EEPROM (would love to use SD but… 
)
In the existing codebase we also have a circular buffer on the SD card to that the logging of events and the transmission are decoupled. There is an onboard RTC that is used if the cloud connection is not available. It is an issue that the SD can’t currently be used with the ethernet, hopefully a resolution is found that enables this functionality.
2 Likes
well, except that on this page
https://docs.particle.io/datasheets/accessories/mesh-accessories/#ethernet-featherwing
there is this,
"The Ethernet FeatherWing is the fastest way to add wired connectivity to your Argon, Boron, or Xenon and turns any Particle Mesh developer kit into an Ethernet gateway."
and best as i can recall this concept of turning a mesh device into an ethernet gateway has been promoted since pretty close to the start of the ethernet featherwing so it's quite a spin, imo, to now assume that wifi & gsm are the only gateways. the product id of the specific combo [eth/xenon,eth/boron,eth/argon] just needs to be formalized in some way. i see it, and hope particle does as well, as another item on the todo list. and if particle can smooth out most of the ethernet featherwing "play" issues, great ! issue a v2 asap.
edit: and another thing, there are some resources that are lost when converting a device for use on the ethernet featherwing which is just part of the deal when setting up the combo , but as far as i have been able to determine it has not been documented how the device can be returned to it's former state or even if it's possible.
Yup, I just think that it is kinda obvious (and a pity) that using already defined pins such as UART2 RX/TX, SCLA1, UART1_CTS etc to drive the ethernet wing is not a good idea when there are 6 unallocated pins available for use in this way. (The eth needs 3 control pins, CS, !RESET and INT - these could easily have been mapped to D6,ADC0 & D8 and all you would have lost was RTS/CTS on UART2 - instead we have lost UART1 RTS/CTS, UART2, SPI1 and I2C1) This is such a waste of extra peripherals that, in my case, are sorely needed.
Granted there may be good reason to have done so - but in my admittedly limited knowledge - I cannot fathom why. It has crippled an otherwise great product, hopefully this can be resolved with V2 (as you mention) release and lets all move on.
1 Like
I wanted to add our use case for a Xenon only product with Ethernet. We have deployed a fleet of Photons to our customers in the industrial space and due to noisy WiFi we haven’t had a great response from our customers, however those with clean WiFi love it. There is also a large section of our customer base that have not deployed WiFi for various reasons, security being one of them.
We want to offer our customers the choice of a Ethernet version of our product and are anxiously waiting.
Agreed - industrial wifi is not that practical esp. when you want reliability. Our product plan features Eth for that very reason as well as PoE to make sure it is fed clean power, since on machine based manufacturing floor, the electrical noise is significant.
@will Any chance of adding the Xenon only with Ethernet to be a product soon? I have a fleet of them and need to update them all to 1.4.0 for a bug fix.
@amillen - I do not believe a Xenon-only product will be available in time to fit your need. However, if you open a support ticket, I will very gladly help you troubleshoot the bug affecting your Xenons and bring them up to a modern OS in an efficient way!