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

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

@badmannen @Yveaux You're absolutely right. I was lazy, only changed a symbol and gave a bad advice. My response should be changed to <=4.

Still I don't understand what the original question was.

It's as easy as trying it.

@yveaux said in Dynamic change of variable name:

That will cause a buffer overrun at the end again...

Really? I can't see why a loop trough 1, 2, 3, 4 could overflow a 5 elements array.

In my code, I manually add 0 (the device itself, for vcc) before entering the loop. So in this case, still 5 elements.

@mfalkvidd said in Dynamic change of variable name:

int myarray[5] would have positions 0 thorugh 4. Position 5 would be outside the array. In the code above, position 0 is never used.

So either make the array 1 element larger than actually needed (with position 0 unused), or let i start at 0:

In fact, I interpreted it more like @skywatch
Notice the <=

 int value[5];
 for (i=1; i<=5; i++){
   value[i] = debouncer[i].read();
 }

I just made something like this for indexing sensors in a node, where idx 0 was the node itself, and thus already filled before the loop.

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.

@rozpruwacz said in Build retry funtionality into the mysensors library:

But MQTT broker is not running on the 1kB ram mcu

I'm not saying to make a mqtt broker run on an arduino. Just picking the process logic as a guideline.
MQTT is not a protocol made for raspberries, it's only that often run on them.

@mfalkvidd said in Build retry funtionality into the mysensors library:

How do you handle if the same actuator is changed multiple times before the earlier changes have been reliably delivered?

How MQTT qos 1 does? I think it should be similar to it.

Also I don't think changes in between should be dropped. That would be like dropouts in a metered system (logged to influx, fEx) and probably do strange things with scenes and group switching.

In my attempts to become a better C++ (Arduino) developer, so I can make those advanced nodes I'm thinking on, I often dismantle and see inside of big avr projects.
In case of MyS, I can't understand how, in an archiectural point of view, can work.

Let me explain: I created a new project in Platformio for ESP8266. Then I took the bare minimum from MyS lib, to be able to debug send a message, and stripped all other content. Even removing the ability for hook setup and loop, removing MyHwHAL and replacing with normal functions.
So it has a main.ino with setup and loop that calls mysensorscore setup and loop.
Other files, with content stripped that still remain are main mysensors.h, myconfig.h and hal for 8266. Nothing more. In hal I only leave debug related content, initilizing serial in hwInit() (called in core without conditional inclusion).

As is, it never compiles. It throws error for two reasons. Core.cpp doesn't see content in hwHal (hwInit, DEBUG macros), and files in hwHal doesn't see the serial macros defined in config.
I tried 4 and 5 times, with fresh projects and I can't make it work. I even thought it was something with the linux/platformio compiler, so switched to VS+vsmicro and then arduinoIDE without any success.

Yesterday I took all the content and incorporated "as is" in order of call in the Mysensors.h file, and it compiled. Then I took out all the files one by one to reveal those two avobe problems in cpps.
Then I took another copy of the bare project and eliminated the mysensors-mysensorscore level. I moved the coding from core to mys.h and it worked well and solved 1 problem. But Still have to reference myconfig in myhwesp8266 for it to see the debug macros.

I'm sure it's my ignorance, so perhaps someone more expert in avr-c++ can explain me how mys library ignores those problems?

@kimot said in My experiences with MySensors:

But you can use one AP for your computers and TV and etc. and other for your sensors.
AP hw is cheap....

Or you can get a VLAN compliant Wifi access point, do the things as should be and implement a separate VLAN for your IoT devices and services.
If you buy, for example an ubiquity AP, you can configure as many SSIDs as you need, each one on it's own VLAN, and even you can specify that the IoT network should only be N-type increasing the range.
By using only one access point you also reduce radio interferences. Radio appliances are not perfectly made and cheap ones tend to be noisy and get worse with the age.

I'm not particulary an ubiquity fan, in fact I only have the ap_ac_pro one, but I'm so satisfied with it that I would recommend their switch+router solution. The web management is awesome.
For my adventures I prefer having an ordinary 10gb d-link switch and a custom opnsense router.

Range of the ap_ac_pro inside a 20m radius house with 25cms stone walls is just in the limit. Just one in the very center. A long range unit would cover anything, but mine is freaking fast. :ghost:

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