Hi,
Very new to all this and i would like some guidance regarding a project I have. I would like to control a solid state relay remotely. At one end, i will have a contact closure coming from a piece of equipment. I would like to replicate the contact closure on a remote unit, max 25 feet away. One of my requirement is to not be connected to the wifi network, so no internet access.
Where do I start?
Regards and thank you all for your help
@transitron - doable but with general questions back to youā¦
The first thing to see about is if we can adequately drive the solid state relay without blowing out the device.
What voltage and current (amps (A); milliamps (mA); microamps (uA) does the solid state relay need/want to close the switch? If unsure what to look for, tell us the make, model, part no, etc for the solid state relay or post the link to a product page.
The digital or analog provide 3.3V (3V3) at a maximum of 25mA for the Photon. If you need more, you may need to consider using the relay shield in addition or as an alternative.
What device are you planning to use? Photon or Electron or Core?
Then how are you planning on controlling it remotely? Can you specifically not access the WiFi, or is an internet connection forbidden at all (cellular for example)?
How far does 'remote' need to be?
I will be using a transistor if needed to make sure I donāt pull too much.
I canāt access the wifi network. They will be installed in places where I am not authorized to connect to the network. So I was thinking I could use SoftAP for both units to be connected adhoc together. They would be about 25 feet apart from each other at a maximum.
@cermak Forgot to tag you on my earlier reply. I read a bit more on what the Photon can do, and despite my very little programming knowledge, hereās where Iām at now:
I have an audio mixer with a channel on/off switch. This switch drives a contact closure I have access to via a screw terminal. At the mixer, there will be a Photon, with a digital pin connected to this contact closure pin.
I donāt want/need the Particle cloud, so I was planning on using WiFi.connect instead of Particle.connect. Not sure yet if I will create a ādefaultā wifi network for my Photons only (standard SSID and password, hardcoded, so I must use SoftAP on the āmasterā device?) or give ability to the customer to connect the Photon to his own WiFi network (SoftAP for the first connection only).
Once the channel is turned ON on the mixer, I want all other Photons to receive this information (probably a variable named channel_on or something?). Some will turn on lights (via a relay board). If users are connected to their WiFi network, I could also use a Raspberry Pi, for example, to get this variable somehow over the network?
I donāt want to infringe any rules, but I would be grateful if someone wouldnāt mind spending some time answering some questions from me, perhaps over Skype (which is sometimes easier than writing everything).
Regards,
Francis
There are a fair number of folks that are trying to use this platform without an internet connection and/or Particle cloud. While not impossible to do, the purpose of this platform is IoT (internet of things). By removing the āinternetā, this eliminates a lot of the built in utilities/functionality that would make this project very feasible.
Should you have āinternetā for all your photons, the āmasterā can listen for the on/off closure of the switch. It would send a Particle.Publish signal to the Particle cloud. Any number of your auxiliary photons would subscribe to the Particle cloud to obtain the signal from the āmasterā. All this infrastructure is provided and would essentially be very plug and play.
If you want to continue down the route of no internet / no cloud (oT), there is a significant amount of infrastructure that you would have to re-invent or re-create.
You could turn a Raspberry Pi 3 into an access point for your photons. You would have to setup the infrastructure on the Raspberry Pi to replace the Particle cloud infrastructure. Once that infrastructure is in place, the photon āmasterā could signal the Raspberry Pi which would then distribute that signal to your auxiliary photons.
The other three pieces is pulling together the server software on the Raspberry Pi to listen for the signals from the āmasterā and send it out to any listening photons. Firmware for the āmasterā and firmware for the photon slaves controlling lights, etc.
It does not matter if you use a Raspberry Pi or a Photon using SoftAP to be the coordinator. You would have to do the same development on the Photon to determine how it receives a signal and then how it needs to be sent to the remaining Photons. At the moment, I donāt have any experience with the SoftAP side of things, so I am at a loss to say how easy or hard this might be.
There are no rules to be broken or infringed. The design choices have implications on the path forward. Choosing not to use the Particle cloud has significant implications for this use case.
@cermak The main reason I am trying to not use the cloud is the cost per month that becomes prohibitive pretty quickly in quantity.
@transitron, if you are using Photons, there is no cost for the cloud. Are you planning on using Electrons?
Well that's not strictly true, commercial users with more than 25 devices in a product have to pay for use of the cloud and this subsidies the provision of free access to hobbyists and developers. However I can't see those costs becoming excessive cases given the effective per unit rate.
However involving & relying on the internet to remotely control something in the same room/building is not necessarily the best approach. You could equally use simpler communications methods like a cable, a 433Mhz RF module, Bluetooth or IR with an Arduino.
The commercial part is in fact where it becomes a bit pricey. I do have an AWS server anyways, so I might use that, given that the number of events/messages will be low, around 30-80 a day maximum.
I could use RF, in fact Iāve thought about it. However, since Wi-Fi is easily integrated into an existing network, itās easier to ensure range inside a building. Also, the precertified nature of the Photon is of interest to me.
I might end up using another precertified WiFi module at some point if the Photon doesnāt make sense anymore, but I really like the Photon.
It's still kind-of true though. The cloud is free, the enterprise level management tools are not. Luckily, no-one is forcing you to create a product on the console. The features there are offered as a (big) convenience, but you could just as well develop a working product without it. That might cost you more on developing time than a console subscription would though. There was a time before the console where commercial products were made 
I had misread the pricing, itās really not that bad after all. I might consider it. The only thing I worry about is if Particle shuts down, iām stuck with a bunch of non-working products.
Then you could still use them like any other internet connected microcontroller, itās not mandatory to āuseā Particle. (Almost) everything is open source as well. Also, they just had a successful fundraiser, so theyāre not going anywhere anytime soon 
Here is another theoretical pathway.
Since the Raspberry Pi was mentioned, you could still turn that into an access point (as described earlier) and then put a copy of the Particle local cloud on it.
If the Pub/Sub works and the wifi is reliable, then all should work -- you publish from your master and all the slaves to their magic. There is a a fair bit of rejiggering to get this all to play nicely.
@transitron - I had a frustrating time working through the various instructions for turning a RPi3 into an access point. I pulled together a summary of commands for the latest Jessie.
I have literally borrowed pieces from just about every instructional post out there. The one thing you do not need is an external wifi dongle. The on-board wifi works just fine.
Next (as time permits): trying the local cloud on the RPi3 and some spare photons.