• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Start Up Queries
Dear all,

could you point me any starter guide?

It took me sometime to get NetPi run with one netpi-raspbain container run. But failed on the netpi-nodered. It is about time to clear some doubts.

Q1, Is it normal that netpi is only accessible from the remote PC in the same network? When I first power up, the conosle seems pending at "update UTMP abut system Runlevel Change". I used to thought the console will prompt the username and password, as a usual raspbian.

Q2. Netpi relies on DHCP of the router immediately above it, otherwise, remote access failed.

Q3. When we access docker, Portainer should appear as a running container, but I don't see it. Isn't it?

Q4. Do we have a command line approach to run a container? I have to configure the resources piece by piece from Portainer->Contianers->Add Container.


Hi there and welcome.

could you first of all confirm you are using a device NIOT-E-NPI3-EN or NIOT-E-NPI3-EN-RE please.

1.) No this is not normal. netPI runs internally a Linux operating system which is using a standard TCP/IP stack to feature the single eth0 Etnernet port. This eth0 port gets an IP address and gateway address from a DHCP by default. With both settings the netPI can be reached from anywhere with its legal IP address outside the local subnet also. For example in the office we have several netPIs running spread all over the building floors. On is located at ip, one is located at ... all these netPIs I can reach from my office notebook with IP without any problems

When you have deployed the raspbian container correctly on netPi as descibed in the containers README here https://hub.docker.com/r/hilschernetpi/netpi-raspbian/ then indeed the raspbian container will ask you for a login name and a password as it is usual for Raspbian OS. On this page you also see that this container has been pulled meanwhile 100.000+ more times. So it is proven in use. For me it seems that the deployment of specifically your Raspbian container was somehow misconfigured in netPI's portainer.io web UI. 

2.) netPI relies on a DHCP server only during the first startup. This is the default setting. But in the main control center you can change the eth0 LAN port settings to a static value, you can change the subnet and also the gateway address manually

3.) No this is not correct. Portainer on netPI is installed natively and not as running container. We did this cause we wanted to avoid that users can disable the portainer.io container in the portainter web ui itself ... and would then lose any configuration possibilities. Portainer web-ui is started automaticall along with the Docker deamon at the same time.

4.) No this is not possible. We decided not so offer the SSH/Console feature since the product introduction in year 2016. The only chance you have with netPI is doing anything across portainer concerning the Docker Management.

You said you have difficulties getting started with netPI. I recommend watching youtube videos I made years ago like https://youtu.be/CB6bYfMbFhA or this one here https://youtu.be/A-asfhl7b0c

You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

(July-14th-2021, 11:41 AM)Armin@netPI Wrote: Hi Armin, thanks, also goes to Ms. Xia.

I went through the youtube clips, it's very helpful. I am working on NIOT-E-NPI3-EN-RE. My first container Raspbian works, and I could sudo update it well.

I checked the status of NPI3 from its HDMI, it pends at "started update UTMP about System Runlevel Change". I assume that's expected as design. and users should access the device through main-control-center.

When you say you could access all netpi from anywhere of your office, must all those netpis wire connected?

It was not easy to get Nodered container downloaded and run. Part of the difficulty was contributed from the public network to dockerhub, partly from the proxy of the remote desktop I am using. Part may contribute from the cache of the browser. In general, I could "docker pull hilscher-netpi/netpi-nodered" much faster from a PI4, than netpi3.

Q1: confusion on nodered status "healthy", not "running"?

Q2: when starting a container, the network attribute could be "host", "bridge".... typically we use "host". can you elaborate on it? If we have a MQTT container runs along side with NodeRed container. If NodeRed takes "host", how to  configure MQTT into container network, so that the broker (server) is "visible" by the nodered nodes?

Q3: Given an Netpi, how can I have MQTT installed natively as Portainer?


yes it is correct on HDMI log output any netPI device prints out "started update UTMP about System Runlevel Change" as last message. This is normal. Because netPI is a secured device there is no SSH service activated on netPI OS as you are use to with standard RPI3 or RPI4. 

I also agree that using docker command cli to control docker engine as on standard RPI3 or RPI4 is sometimes easier than using portainer.io web tool to configure docker and containers. But if you got familiar with portainer.io after some deployments then it is much comfortable.

Q1: If you have configured hilscher node-red container well, then it ends up in the container state "healthy". This is a Docker feature you can enable for each container and makes a life check if the main application running in the container is still alive. And our hilscher node-red container supports this feature.

Q2: Yes it is correct that the hilscher node-red container needs to be configured in mode "host". But you are not bound to use the hilscher node-red container in any case. You can also deploy a common and standard node-red container from here https://hub.docker.com/r/nodered/node-red/. This container does not necessarily be configured in mode "host" and can run in mode "bridged" also. It is your choice which one you want to use and of course it depends on what you want to realize as your final application. But since hilscher node-red container is sepcial and supports things like bluetooth also or the onboard industrial network controller chip for real-time ethernet communications ... all those features need direct hardware access and this is why hilscher node-red container needs to run in "host" mode.

Q3: In order to install MQTT broker on netPI I recommend this one here https://hub.docker.com/_/eclipse-mosquitto. Since you are describing you want to access from netPI node-red container (which is running in host mode) to local MQTT broker which can run in "bridge" mode use the containers IP address as destination in your node-red MQTT in/out node.


For more details about how to get it running read on this thread https://forum.hilscher.com/thread-269.html. Mosquitto container by default is unconfigured and need edits in mosquitto.conf file as explained in the thread. If you do not modify the *.conf file Mosquitto MQTT broker will not work

Q4: see thread https://forum.hilscher.com/thread-269.html. I have tested it just a minute ago and got my MQTT node connect to my local mqtt container

.jpg   mqtt_broker.jpg (Size: 4.74 KB / Downloads: 17)

You never fail until you stop trying.“, Albert Einstein (1879 - 1955)


Possibly Related Threads…
Thread Author Replies Views Last Post
  docker.service start failed EUROKEY 13 3,474 January-17th-2021, 07:52 PM
Last Post: Armin@netPI
  Cannot start container Magnus 7 1,964 October-16th-2019, 01:00 PM
Last Post: Armin@netPI
  [SOLVED] Portainer does not start container Steres 3 2,696 October-16th-2018, 06:54 PM
Last Post: Armin@netPI

Forum Jump:

Users browsing this thread: 1 Guest(s)