I partially run my IoT implementation on docker. Today I was trying to test a mqtt broker inside docker. I always create my containers with permanent volumes and I maintain a separate folder for containers in my nas.

I installed all kinds of containers and pointing the storage to their config folder like -v /mnt/docker-data/mqtt/config:/mosquitto/config always worked. But mosquitto didn't want to run using remote volumes. Always complains about not being able to access the config file:

1565537402: Error: Unable to open config file /mosquitto/config/mosquitto.conf.

It doesn't matter if you try to change the owner of the folders or even give rwx to anyone.
After studying the project's dockerfile and folder structure I came to the conclusion that it's not prepared to be installed in one go, using persistent volumes (can be done in two execs). The project docker directions are not so clear and seem to be made for auto-consumption (like not providing a default configuration file)

So I made a small snippet to properly install and do a minimal configuration for the mosquitto container, pasted below.

Usage: # ./mqtt.sh /mnt/<thefolderwhereyoupersistdockervolumes>

#!/bin/bash
VOLUME="$1"

# Only if persistent volumes/configuration doesn't exist >>>>>
if [ ! -d "$VOLUME"/mqtt ]; then
  mkdir -p $VOLUME/mqtt/config $VOLUME/mqtt/data $VOLUME/mqtt/log

  curl https://raw.githubusercontent.com/eclipse/mosquitto/master/mosquitto.conf -o $VOLUME/mqtt/config/mosquitto.conf
  cat <<EOT >> $VOLUME/mqtt/config/mosquitto.conf

persistence true
persistence_location /mosquitto/data/
log_dest file /mosquitto/log/mosquitto.log
EOT

  chown -R 1883:1883 $VOLUME/mqtt
fi

docker run --name mqtt --restart=unless-stopped \
  -p 1883:1883 \
  -p 9001:9001 \
  -v $VOLUME/mqtt/config/mosquitto.conf:/mosquitto/config/mosquitto.conf:ro \
  -v $VOLUME/mqtt/data:/mosquitto/data \
  -v $VOLUME/mqtt/log:/mosquitto/log \
  -v /etc/localtime:/etc/localtime:ro \
  -d eclipse-mosquitto

docker exec -it mqtt mosquitto_passwd -c /mosquitto/config/pwfile iot
# Add to a shared network between iot containers. (Node-Red, InfluxDb...)
docker network create iot
docker network connect iot mqtt

Notes: This snippet is stupid. It doesn't care what he gets as parameter, for example. So be smart when using it. And remember not adding the name of the container to the route. He always adds and assumes "mqtt"
Sample parameter: /mnt/docker-data will create: /mnt/docker-data/mqtt so take into account if you already have that folder.

@scalz Regarding WiFi I'm not saying that mysensors should overcome the problems of crowded or noisy environments. I'm just saying that if that's the war field, it should have slided to another one.

I spent more than 4 years on those problems. I'm physician and software architect/analyst, and my father was ham radio fanatic. Not boasting, only saying that I have a minimum knowledge. I created a nice environment with only one WiFi device, good ubiquity equipment, with nodes without boards or ground planning issues, studying the band and choosing channels and still had nightmares.

Yesterday I learned how to easily hang a node by sending a message to it. That shouldn't be possible.

I'm not saying that this is crap or that this doesn't worth playing with it. Only think that it needs some love on the low level even if it has to move to slightly powerful devices. Or adding capabilities on powerful architectures while still supporting the good old ino.

Perhaps combined with a custom nrf52 development board or something to make easier burn and solder them. Make an nrf52 mysensors starter kit, and convert sensebender to it.

Sorry, as you said I don't have the knowledge to make long run boards to contribute with them.

In the past storms season, our garage door board fried, so I replaced it with a new one using mysensors.
It has double power supply, the door motor is on its isolated own.
But I was having this strange behaving. Sometimes when opening or closing the door, it will stop after some centimeters. Then with my click it will go back until completely open or closed. That's strange alone, but in some cases, it will then start again without command and do the complete travel. Coming from an stop interrupt that would be impossible.
Also, if I insisted clicking or stopped this movement it ended in the gateway being hung and I had to restart it along with the rpi.

I thought it was caused by duplicate orders sent back by controller, echoes or so, So I Incorporated two things:
While travelling, it doesn't do anything more. Nothing is sent back to controller.
And, after an order is received, decline all to follow for 1-2sec.

The door now behaves immaculate, without any fail or hesitation. The gateway hasn't hung since the change.

In my opinion, and a way to leave this topic, I find the project is a bit uncoordinated. (There are some brilliant people there. That's out question)

I mean, we have the mysensors library, that needs slight configuration when used in nodes. But definitely one must set some things, as channel. (Other things are part of the hardware)
Then is signing and encryption. And it's understanding and use is not trivial.
Then nodemanager and mysbootloader.
Every "module" by its own.

The bootloader has the ability to rewrite the program in the node. It could be feasible to parametrize security and operation settings (in EEPROM?) and the bootloader set them initially only requiring radio settings being hard coded.
And those ones could be added as parameters to bootloader compilation.

That should make something more useable. But someone must have already thought about it. I'm not that clever.

I've already started some interesting things myself, but always abandon them by fear of project changing paths , little time to invest at the right moment, or simply not being a popular contributor.

I'm a .net programmer and been waiting the opportunity to do something for emby in this platform. If someone know about the recent "changes" in that project, will understand my sadness. So when I saw a not so friendly project I start to fear.

@scalz said in Fewer home automation postings? What's behind it?:

I can't tell you more

Yes, that's what I was referring to. But anyways, I should be ignored again.

Edit: definitely should.

Voilá.
And it maintains a live inventory of clients.
Some points are so difficult to achieve. But I was looking at message identification as a response to the sequence switch problem.

I just assembled my first OH! My... board and realized that the V2 sketch doesn't work for me.
Anyways I'm posting a sample sketch for testing the board:

#define RED_PIN 3
#define GREEN_PIN 5
#define BLUE_PIN 6
#define WHITE_PIN 9

#define ON 100 // Please, don't burn my eyes
#define OFF 0

#define ON_INTERVAL (3*1000ul)

void setup() {
  // Setting pins to output and low is not required for analogWrite.
    Serial.begin(115200);
}

void loop() {
    analogWrite(RED_PIN, ON);
    Serial.println(F("**RED**"));
    delay(ON_INTERVAL);
    analogWrite(RED_PIN, OFF);
    analogWrite(GREEN_PIN, ON);
    Serial.println(F("**GREEN**"));
    delay(ON_INTERVAL);
    analogWrite(GREEN_PIN, OFF);
    analogWrite(BLUE_PIN, ON);
    Serial.println(F("**BLUE**"));
    delay(ON_INTERVAL);
    analogWrite(BLUE_PIN, OFF);
    analogWrite(WHITE_PIN, ON);
    Serial.println(F("**WHITE**"));
    delay(ON_INTERVAL);
    analogWrite(WHITE_PIN, OFF);
}

@scalz C'mon, would you leave the forum with just one hit?
In fact I understand your point completely. Open source has become more and more caotic. Internet is atemporal, and often people has the bad habit of not putting the complete date at the top of their "articles" that makes that search engines cannot filter and order properly.
Everyone has a blog and writes whatever gets out him. The majority of people uses that as a remainder for themselves and... whynot getting reward. So there are zillions of howtos made anyhow. They are not written for helping people.

If the sources and destination are always one, why there aren't the binaries available and all writeups talk about messing the computer and compiling? I think that's because nowadays people seek praise for having achieved it.

Scalz point is about economy of time. Because time is money, even if it's spare time, and yes, a paid/proprietary probe becomes cheap, giving the documentation on the internet, today.

Also the point of view depends in the situation of everyone and its age. Someone at the 5thies feels earlier that it's wasting time, and there comes frustration, and complaining posts, unfortunately
Just buy a probe, forget about it until it gets delivered.

@monte BTW, I was trying to program an stm32 board with a jlink. Not a Jlink. Maybe if there was a way to get an already compiled binary (to avoid all those dependencies errors) and program the jlink with a normal serial ttl...

Nice topic.
I was gonna to say, thought it may seem Overkill, that you could setup a small zone minder system with a cheap night vision camera pointing downwards as high as possible.
Then zm allows for setting up virtual fences by drawing on the camera image, and if anything changes in the region (with configurable threshold) it fires a trigger or alarm.
You could start the sprinklers.

I would like to have a domoticz integration plugin.

I've been working on an sketch for this board. Somewhere in the path I started adding functionalities and it ended in a library. Perhaps it's way overkill, but I thought that could be easier add it to NodeManager like that.
It's based on the work done here and some more ideas around the network. Thanks to LastSamurai for the board and code and also to Jan.
You can find the sources there: https://github.com/SergioRius/RGBWDimmer

This thing includes a serial manager that I use myself, but you can remove it and delete all the code for debugging, and perhaps add yourselves if necessary.
Just clone the repo or download and install as a zip library on Arduino IDE.
The example works for the OH! MySensors RGBW board as is.

It's very self explanatory in the code, but in essence:

• It can be used stand-alone or with mysensors
• You simply send to the commands and the class does all for you.
• Uses a non blocking system for the fading.
• Configurable fading time and resolution
• Several configurable fading curves
• Option for gamma (brightness + hue) calibration.

I'm currently debugging the fading curves equations other than linear, as the arduino mcu capabilities are tight and it's so easy to overflow it. Also I'm doing a program for calibrating the hue (arduino with leds and a rotary encoder for manually adjusting), so for now gamma only compensates brightness. You can change the values if you prefer. I'll be a good idea to lower the white channel.

It still lacks some memory optimization, but for now I'm scared about overflows. I got one of those and it was a two days nightmare and I had to revert to ints to get something running.
I'll soon add a stand alone sample and port to NodeManager.
For the while, for using it alone the minimal it's:

#include "RGBWDimmer.h"
RGBWDimmer myDimmer(1, 3, 5, 6, 9);  ///< id (to remove), Red Pin, Green Pin, Blue Pin, White Pin

bool JustDontBlockLoop = true;

void loop() {
  if(JustDontBlockLoop) {
      myDimmer.setNewValues(255, 0, 150, 0);  ///< RGBW decimal values. If you prefer hex, use setNewValuesHex
      myDimmer.StartFading();
      JustDontBlockLoop = false;
  }
  myDimmer.loop();
}

I hope you like it. And if you have any idea for adding functionality, please tell me.

@scalz After the "cleaning" there should be an example on each supported endpoint platform. I mean, if rj45+mqtt is supported, rfm should have a working example with all the components (level adjusters, etc...)

The big problem with rf24, said that it's so dependant on the environment, is that different countries have different regulations. And could be that what seems perfectly ok for some or all developers, doesn't work for other people in their houses.

Documentation doesn't say anything about checking country's wireless regulations as it's neglected.

@alex28 In my opinion you are presenting fair points.

@ramwal I'm sorry for my late response. And I'm glad you solved your problem.
In my case, the board just kept giving problems and problems.
It started with aberrant readings from the sensors. I sent it back only to be told that the board was perfect.
When it came back I had a condenser failure and after the fix, intermittent serial bus fail (all leds on and hangs at simple debug prints)...

...until one day, it mysteriously jumped into a rain puddle (while still connected to the battery pack, from a considerable height). So I said bye and never look back.

@tmaster WiFi devices will behave as you program them, there are several "conventional" projects there for them, like espeasy, tasmota, espurna (my preference) and with luck one more by the next year.
They poll the network for several things, like mqtt and ping status messages. Some are configurable.
But on top of that, there's own wifi ttl, leases and other green implementations that need re-registering from time to time.
So for battery powered devices could be tricky as that increases drastically wakeup.

I had once a problem in a company where mobile devices where repeatedly disconnected from Cisco APs, due to a bad ttl config in them. That's how I know about it.

Also... Continuing with the supposed vulnerability in the article. If you correctly program the arm chip, not with fancy joke web portal, but with secure protocols, etc... And then as the article says, you set the fuses to avoid firmware changes...
Where extreme risk would be? (Legit question)
Those chips are cheap enough to start consider them as one use.

This article @NeverDie published doesn't involve or talks about WiFi. It talks about physically accessing the chip and messing signals to program it.
That is a nonsense if you already have physically access to the device. And it should apply to any device.

That is what I mean. WiFi has been a nice word in the mouth of everyone for decades. It's so easy to simplify and confuse using a word as a flag.
If a company created a new ideal device for mys and this device would be easily hacked, would not mean that mys is the culprit or bad.

That's like saying one would never travel by plane because accidents happen. Your simplifying in excess the wifi concept.

Tell me how a WiFi connection can be hacked, if it implements an "inclusion mode"

@skywatch said in WI-FI IOT modules:

It does not support VLAN however

It's not a L2 switch? What is it?
In fact, switches only have to comply to 801.1x... whatever for vlan "passthrough" it's the router that's managing it. Also wifi APs has to be able to bring up several ssids and tag them.

I have opnsense virtualized in my server as the router, and a small physical shitty appliance as failover.

But @alowhum mysensors only works bc it's not widely used. You know what I mean. Just imagine a building with as mys installations as WiFis you can get nowadays.
And don't even think on phone telling your mother she has to modify bootloaders, firmwares, to switch a channel that perhaps it's also occupied. It's not realistic.

Anything can be done though. Those are tribulations, like wondering what will be next on cars, electrics or hydrogen.

Ok, send me your address

RF are not more secure. Kids spoofed garage door key fobs for decades and now are used to do more complicated things with cars. We are the accommodated ones.
Nrfs are also jammed at the same time that WiFi.

A good starting point to learn to do things with network is open-wrt. You can flash almost any router and start playing (and repurpose them for other things). And today you can find retired good L2 switches on eBay on a budget.
DLinks are very friendly, don't jump on a Cisco only bc they're cheap. (Or HP )
Professional & Soho switches have nice features like Poe & unused ports power down. With 48p or more they can be hungry beasts.

It feels wrong to me when someone says that WiFi (and by extent private networks & appliances) is extremely insecure, being what it is, with so many years of development.
Today there's everything for WiFi. And WiFi is not a protocol nor a transport.
How many here run their inet provider access point? That's dangerous.

Start learning about vlans, network segregation, AP mesh and redundancy.
And there are some tricks for l2 enc & auth.
Got to know the infrastructures of today houses.