I am relatively new to RBP3 and what it can do, but Ill try to summarize what I want to do and maybe I can get some pointers in the right direction.

So the idea is to have a web app running on a PHP server connected to a regular database. The RBP acts as a middleman. When a user enters a code on the website, the RBP (which is stored off-site) sends a signal to a switch relay which in turn triggers an unlock mechanism to a specific door (based on the code entered by the user).

I have provided an image of how the flow is supposed to go. Flow

I am a bit confused in which end to start. But the idea is that the web server sends a request to the RBP. For this - would I need a web server running on the RBP, or is it possible to accept/send requests from a single IP address without configuring a whole apache web server on the Pi?

As you probably can tell I am a little lost in which string to pull, so what would your suggestion be for handling the incoming requests and the possibility to send requests?

EDIT: I will try to provide a bit more clarity in this. The doors are connected to a WAGO coupler, which in turn is connected to the RBP over VPN.

The role of the RBP is to recieve a request from the PHP Server, check if the door is open or closed, and if it's closed it will send a signal to the coupler to open the door. The RBP will then send a message back to the server saying the door is now open.

From your replies I have realized HTTP might not be the best protocol, and I will instead look into MQTT and other protocols for this project. I might be biting off more than I can chew here, but I really need to get this to work which is why I am looking for a bit of guidance.

Thanks

Instead of web server doing HTTP request to RBP it is much easier to connect from RBP to MQTT Broker and subscribe to some topic. Once Web server will receive some request it can publish message to the Broker and RBP will receive it. Thus it will eliminate the need for RBP to have public IP.

You may install own MQTT Broker on the same host as Web server or look into any cloud/public brokers.

In order to send message from PHP you may use mosquitto_pub or for some brokers there are REST API that you may use, like in this sample.

It seems like you might have the problem arranged in a slightly odd way, unless there are details which are not described in the question.

You show the doors connected to something 'on premises', but it's not your SBC. So maybe you have something unnecessary in your architecture here.

You're also implying that the connections are initiated by the cloud/endpoints, not your central device. A more normal approach would be to move the SBC into the 'hub' position, and initiate a connection from here directly to your web server.

To answer the question, yes, I believe you do need a web server if you want a web server.

If all you want is Machine-to-Machine signalling over an IP connection, you might want to look at something like the CoAP protocol. Also bear in mind that you already have one web server in your architecture, and you might not need another.

  • Hi, thanks for the reply. I'll try to explain a bit better how the setup is going to work. The idea is to connect the SBC to some kind of WAGO coupler through a VPN box, and the coupler is connected to the switches steering the door locks. So essentially the doors are connected to the SBC, just over a remote connection. This is due to not being able to be at the doors' location to set things up, so we will have to do things from two ends. The role of the SBC is basically recieving a signal from the web server, checking if the door is closed, open the door then send a message back to the serv. – user2868900 Nov 1 at 9:05
  • OK, that doesn't fundamentally change my answer (which agrees with the other, HTTP is not the best protocol). Do update the question though, it will make it easier for others to provide insight. – Sean Houlihane Nov 1 at 9:07
  • Thank you, I've updated the question and will look into other protocols – user2868900 Nov 1 at 9:13

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.