Best posts made by Sergio Rius

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.

@tbowmo Thanks Thomas, I was trying to make an ENC28J60 module work with RF24 then RFM69, and I was getting crazy at it. Finally the module was a failed one. I'm so embarrased, as I was convinced I first tested the module on arrival, and I missed the point.
I've already ordered a W5100, but it may take weeks.

@rozpruwacz Thank you for your help. I just realized the cause of the issue and just now saw your reply.
I power the set through the usb port from the Nano. And the pro minis where brand new, so that was very strange.

The problem is that my wife has 4 new kitties. Yup, that's it.
An hour ago I started a meditation session, vulcan style. Then I recalled those past days having to replace some wires being bitten. So I got my BF...lens and took a look to the wires, they were all Ok, but the cap I use on reset took a small but fatal bites. as I replaced it the board begin to send back signals to the programmer. Also those new Minis I bought seem not being so quality ones. The blink sketch they have creates coms interference that I have to burn a blank sketch first.

Damn, this was driving me crazy. But they are so lovely... hehehe

@mfalkvidd THANKS!

@mfalkvidd Oh! Yes thank you very much. The fact is that a typo in the description of the product I bought (838 != 868) is what confused me.
Now thanks to you I realized it.
I'll stick with 868 and see if I can work with it.
I live near a frontier with Portugal and those guys here doesn't care about pirate radio emissions and I get strong interferences in radio, wifi and over all 2.4ghz. 433mhz even doesn't have more than 2-3mt of range for me. 2.4ghz only around 7mt @ sight. Bluetooth headphones have dropouts even carrying the phone with you.
All of this living in the country. It's very annoying.

Of course, projects are always difficult to manage and often they must be completely flipped like an omelet.
But what seems recurrent is that only a small group of people knows whats the next step in development. So someone starts doing anything and by the time he wants to pr discovers that the sources had changed path and what he has done, now doesn't make sense. Or simply, opinions and ideas are ignored as they happen to be incompatible or undesirable for the (secret) idea of the project.
I think is something inherent with open source projects. But sometimes is discouraging.
I think it may be solutions for publishing wanted changes and preventing people annoying developers.
I would like a future where desired functionalities would be published in a list and anyone could sign for doing them.

Sorry if words look rough, I assure is not intended, I still have problems with the english.

Thaaanksss! I'll give it a go

For some time I had issues with mysensors communications that prevented the deployment I had planned. After dedicating some time to rebuilding for better debug, I have finnaly found some problems:

• The use of fake/cloned radio modules. Everything has been said. It masked the problems and prevented me to debug properly.
• Domoticz unwanted replies that where interpreted as new commands. I never thrust on Domoticz, and after changing for node-red, that allowed me to better debug communications and see that now and then, Domoticz is replying with a message that seems to announce it's capabilities with respect to the received node and value. It's like an ack, but with a relatively big content, with unwanted things like battery management capabilities (even to connected devices). Those messages where interpreted by the node as new commands and, for example, it made my garage door node to stop while it was opening or closing, without any notice (with the problems it represents). Also those messages sometimes interrupted devices presentation.
• Gateway going lazy after some time.

The two first problems are easy to solve and I have them under control. But this last problem is what is drawing me nuts. It appears in MYSController as the communication activity becoming slow.
I have several devices and one of them is an 8-channel power meter that it's embedded inside my home power distribution box. It monitors each phase of the installation and has a small screen for instant measurements. So far has been a great help detecting failing appliances with residual consumption, as I made it with a great low power resolution using adc chips with amplification.

Well, this device sends a minimum of 6 values in a row each minute. When the problem in the gateway is present, those values appear in the debug window as one every two seconds and after the third all get lost. I noticed that the values for total consumption and kitchen where so deviated, and checked that the screen showed real fresh values and it announced sending the data.
For temp/hum sensors, gw misses one of the values.

When this happens, the only solution is getting a stair and reaching the gateway in the ceiling and turning it off-on. After some hours, it happens again.
Can someone help me to fix this problem? Or sending me advice in how more the gw can be debugged?

The gateway is a nodemcu Lolin v3 board with a direct soldered wirings to a genuine pa-lna rf24 factory shielded radio. Has a cap. It is powered from a good and clean power source.
It's burned now with the default v2.3.1 library and I removed ArduinoOTA and the web portal I implemented, so using the default espgw example. As I'm later converting received serial data to mqtt, I also tried with the mqtt sketch in case that induced some problem, but had the same results.
GW debug doesn't show anything bad. I don't see any problem with wifi. I have good control of my network.

Any ideas?

@yveaux said in MY_RF24_IRQ_PIN on ESP8266 GW:

True, and next it doesn't use it?

This could be reformulated as an affirmative sentence.
I cut the bridge wiring and continued working as nothing happened.

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.

@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.

@alex28 In my opinion you are presenting fair points.

@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.