Inspired by this question: How can I send images from a webcam using a Raspberry Pi?

The premise of the question is to use a Pi to send images from attached web cams to some point in the web. The ultimate goal of the OP is to create a self-driving car which is controlled or monitored (I think more the second) via an IoT platform in the web.

Why am I making a meta post of it?

After the last edit and the reopening of the question thereafter in strategically unfortunate time spans nine close votes have been cast, aged away, others have been cast, aged away and so forth. There were two leave open from the review queue as well. Nine close votes is quite a large amount of our close voter pool which led me to put the question on hold today.

However, in many other meta questions the IoT-ness or necessity of IoT use cases is mentioned for a question being on-topic. The OP does want to achieve something which seems very much like an IoT use case. It's just that he hasn't gotten quite to the point of having an IoT problem.

Either way the community apparently didn't feel strong enough to close the question without the help of hammering it shut.


3 Answers 3


This is a poor question, and I think that is where the problems start. I think it's apparent from the edits to the question over time that we're not being asked something specific here, rather we're being asked to train someone in an area which they have limited understanding - something this platform is not designed for.

What is being asked here (uploading webcam images) has been done many times, in many different ways. My 3D printer sends me PushBullet messages (using octoptrint). Security camera, astronomy, birdwatching, etc. applications have been written for the Pi since it gained a camera.

Whilst we might want to encourage people to innovate in the IoT space, we need to avoid the temptation to try and help people unless we've got something concrete to contribute. Poor quality questions damage the site (discouraging the more expert contributors), and lead to answers which won't help people in the future.

We can't realistically design whole systems for people - it's better to help them understand what they need to investigate to do the design themselves.

Just putting an IoT slant on a question doesn't make a poor question acceptable here. Maybe this particular question would have been better received on a R-Pi forum - at least one aimed at beginners, but it comes across as 'teach me the full stack, so I can go and build something cutting edge' which is clearly nonsense.

There could be questions generated from this project which are on-topic, but before deciding if the question is on-topic, we need to decide if it's too broad. This is a great example of a question which is both too broad, and not solely on-topic (by virtue of the overlap with generic software).

If it was about a subject that was usefully on topic, it would have been narrowed down and fixed by now. As it is, I think it needs to be closed.


To address the question as asked more directly, consider these two questions:

  • if I ask about building an SMPS for a battery powered IoT device:

This is not on-topic just because it's about an IoT application, it should be asked on EE.SE. However, questions about system architecture which affect power constraints (measurement interval, local processing, buffering) are very much on topic - even if they are similarly generic design questions.

  • if I ask about ways of implementing a 'person present' detector and interfacing that to an MCU

This is again a generic question which ought to be on-topic on EE.SE. However, it is also on topic here because this is a particularly relevant application which can be addressed by different approaches and again the most suitable approach will be influenced by the whole system.


I think the main issue here, mentioned by Sean, but deserving really unique focus, is that not only is the possible IoT end goal mere speculation, the present problem being addressed in the question isn't IoT unique at all.

A main point of the Stack Exchange system is that every user's problem doesn't need to be a new question. People with good information acquisition skills generally solve the overwhelming majority of their problems by reading the existing questions and answers, not by posting new ones. By addressing generic problems which have already been heavily addressed elsewhere again here, we create a new, smaller, and inferior pool of questions and answers on that topic, cut off from the main collection of these elsewhere. For askers who don't habitually check the existing questions first, we have the close-as-duplicate functionality - but we can only close as a duplicate against an existing question on the same site - which won't work when the applicable existing questions are elsewhere.

Additionally, the IoT site is not where most of the people knowledgeable about the Raspberry Pi spend their time (it has, for better or more likely worse, its own unique SE site). Posting the question here gives it an artificially limited audience. And in the SE system, users are not permitted to cross-post, so posting it here means they aren't posting it where it would get the best answers.

Ultimately, a question belongs here (rather than on EESE, Arduino, Stackoverflow, or Server Fault, or in this case the SE site dedicated to the Raspberry Pi) if and only if the IoT aspect of the question is more central to the actual problem and its solutions, than the underlying technology aspect is. If not, it belongs on the site where the technical problem at the core would normally be addressed.

Some might want to take a permissive attitude and allow questions here even if they better fit (and already have duplicates) elsewhere, but this causes real harm in two ways

  1. A question asked in a non-optimal place is a question not asked in the optimal place, as cross-posting to multiple SE sites is not permitted

  2. A question asked in a place with a small expert audience for the actual subject matter tends to get bad answers with factual errors. On a site with a real pool of expertise on that topic, these tend to be quickly outweighed, corrected (or yes, shouted down by a chorus of indignant objection) while on a site without a pool of technical expertise they can instead be allowed to remain unchallenged (or even upvoted as they sound informed) - confusing not only the asker, but future readers as well.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .