Hi,

@tbowmo maybe you can help with this:

I would like to use the myscontroller node from node-red-contrib-mysensors to assign and track my node IDs, but I am struggling with the details.

myscontroller seems to read the incoming msg, but when double clicking on it, id is "undefined".

Here are the relevant nodes:

[{"id":"8aa619bf.bcddb8","type":"myscontroller","z":"a8b8ec2f.f6e17","database":"839402cc.e6ba6","name":"node_controller","handleid":true,"timeresponse":true,"timezone":"UTC","measurementsystem":"M","mqttroot":"mysensors-in","x":740,"y":660,"wires":[["ca58e694.77646","da1a60bf.fddd1"]]},{"id":"d1caae4a.7e6d08","type":"mqtt in","z":"a8b8ec2f.f6e17","name":"","topic":"mysensors-out/#","qos":"2","broker":"708db7ae.68d95","x":300,"y":660,"wires":[["4abb49a2.3b382"]]},{"id":"4abb49a2.3b382","type":"mysdecode","z":"a8b8ec2f.f6e17","database":"","name":"","mqtt":true,"enrich":false,"x":530,"y":660,"wires":[["8aa619bf.bcddb8"]]},{"id":"da1a60bf.fddd1","type":"mqtt out","z":"a8b8ec2f.f6e17","name":"","topic":"","qos":"","retain":"","broker":"708db7ae.68d95","x":1020,"y":660,"wires":[]},{"id":"839402cc.e6ba6","type":"mysensorsdb","z":"","name":"test_db_1","file":"/home/blub/test_db_1.sqlite"},{"id":"708db7ae.68d95","type":"mqtt-broker","z":"","name":"mosquitto-betty","broker":"localhost","port":"1883","clientid":"","usetls":false,"compatmode":true,"keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthPayload":"","closeTopic":"","closeQos":"0","closePayload":"","willTopic":"","willQos":"0","willPayload":""}]

And the relevant sketch code:

#define MY_DEBUG
#define MY_RADIO_NRF24
#include <MySensors.h>
#define CHILD_ID 1
//#define MY_PARENT_NODE_ID 0
//#define MY_PARENT_NODE_IS_STATIC
#define SN "Worktable RGBW"
#define SV "1.6"
[...]

void presentation(){
	sendSketchInfo(SN, SV);
	present(CHILD_ID, S_RGBW_LIGHT );
}

When I restart the node, it actually gets node id 1, no matter what I do with myscontroller.

My configure is:

/configure --spi-spidev-device=/dev/spidev0.0 --my-transport=rf24 --my-rf24-ce-pin=2 --my-rf24-cs-pin=13 --my-rf24-irq-pin=21 --my-gateway=mqtt --my-controller-ip-address=127.0.0.1 --my-mqtt-publish-topic-prefix=mysensors-out --my-mqtt-subscribe-topic-prefix=mysensors-in --my-mqtt-client-id=mysensors --my-mqtt-password=blub --my-port=1883 --my-mqtt-user=mysensors

I think I am just using the wrong topics, setting and combination of nodes.

When I set the topic in myscontroller to the publish topic, the following message spams my broker:

mysensors-out/1/255/3/0/6 : msg : Object
object
topic: "mysensors-out/1/255/3/0/6"
payload: "M"
qos: 0
retain: false
_topic: "mysensors-out/1/255/3/0/6"
_msgid: "f5d62d35.d8df2"
topicRoot: "mysensors-out"
nodeId: 1
childSensorId: 255
messageType: 3
ack: 0
subType: 6
origin: 2
messageTypeStr: "C_INTERNAL"
subTypeStr: "I_CONFIG"

Hi,

for anyone creating a gateway on an Orange Pi PC using armbian mainline (4.x Kernel): The fex modifications are not necessary any more. As noted before by @Roman, the device tree needs to be modified.

If you use the exact same pins as in this guide for the Orange Pi PC, SPI0 needs to be activated instead of SPI1. (Pi Zero and PC are kind of pin compatible, but Zero only has SPI1 routed to the header, whereas the same pins on the PC have SPI0. On top, the Orange Pi PC also has SPI1 but on other pins):

verbosity=1
logo=disabled
console=both
disp_mode=1920x1080p60
overlay_prefix=sun8i-h3
overlays=w1-gpio uart1 spi-spidev spi-add-cs1
param_spidev_spi_bus=0
param_spidev_spi_cs=0
rootdev=<removed>
rootfstype=ext4
usbstoragequirks=<removed>

Attention: Header pin 26 is different between Pi PC and Pi Zero. On the zero it is PA10 but on the PC it is PA21. I connected the interrupt pin of the nrf24 like in the guide (header pin 26) and changed the configure command accordingly.

So the full command to use SPI0 and the interrupt connected to header pin 26 of the Orange Pi PC is:

./configure --spi-spidev-device=/dev/spidev0.0 --my-transport=rf24 --my-rf24-ce-pin=2 --my-rf24-cs-pin=13 --my-rf24-irq-pin=21 --my-gateway=mqtt --my-controller-ip-address=127.0.0.1 --my-mqtt-publish-topic-prefix=mysensors-out --my-mqtt-subscribe-topic-prefix=mysensors-in --my-mqtt-client-id=mysensors

The rest of the guide is still valid, except that the transport is now called "rf24" instead of "nrf24". @mfalkvidd can you correct this maybe? Also, the -d switch seems to be not existing any more.

@pii

• Does /sys/class/gpio/gpio24/direction exists?
• Does /sys/class/gpio/gpio24 exists?
• Can you write to them using echo?

i'm sorry, i do not have experience with encryption. essentially it depends on the code you want to write, since on the pi you are kind of limited to scripting, whereas microcontroller code is closer to hardware. also, if you need things like an adc or spi you're better of with a microcontroller. if it's just about some LEDs lighting up..

If your conditions are

• 3 LEDs: yes through GPIO
• Ethernet: yes (d'uh)
• beefy enough for software encryption: I guess? For an IoT-low data rate scenario for sure

I'm running armbian on my Orange Pi and setting up mosquitto is a breeze. But you don't need a broker right? Don't forget you need an SD card on top and more power.

@awilner I am in a hurry right now so I cannot go through what you wrote in detail, but maybe my post about pin numbering can help you: https://forum.mysensors.org/post/58309 It is related to an OPi Plus2e using nrf24 but the numbering formulas should still be valid.

Good luck!

Incredible, good job!

What do you mean bu that though

@rakeshpai said in Browser-based firmware generator:

It doesn't work.

From my perspective it does work ;)

@NeverDie

I understand but tend to disagree ;)

Out of curiousity: Why did you use a through-hole AVR and not a SMD one?

The ID shouldn't matter..

What is the lock item? Showing the status of the lock?

Interesting that those get added to your files, for me the items that I add through Paper UI are not reflected in the folder structure, which is quite annoying...

Checking https://www.mysensors.org/controller and https://www.mysensors.org/download/serial_api_20 it looks like the lock stuff should be fully supported by OH, weird. Did you ask in their forums? It's superactive actually...

Well, if you only need static voltages: 12 and 5 you already have and for 3.3 I'd get LM2596 or XM1584 regulators depending on current needs. But then, this would not really be a lab PSU which is by definition adjustable ;) A common design is the EEVBlog one. Nasty stuff though, I honestly wouldn't do it myself and rather spend the 150EUR...

SPI can be blazing fast. A colleague of mine recently implemented some memory interface in the range of two/three digit MBits per second. Intuitively I would say bit banging an 8 bit parallel data input using a microcontroller is slower than using high-speed SPI. Just polling the 8 bits from the pins will take ages...Of course I am assuming you're using a uc and not a FPGA.

You need to be precise, just because you can read data faster doesn't mean you can process it faster. I'd be a bit shocked to hear that an accelerometer could produce more data than a standard uc SPI can take...but then, I also have no experience.

So I'm also curious what you are planning to do!

@mfalkvidd: I agree and know that MySensors is not built upon a mesh topology, however, couldn't each MySensors node act as a repeater for the above use case? I'm not using the repeater stuff so I am curious...

@gohan @AWI I understand, so the main issue is that CHANGE does not work. I checked the datasheet and INT0 and INT1 can also do CHANGE so it's a bit weird:

Of course you're limited to the INT0/1 pins then.

But also:

So PCINT is just not implemented in MySensors? Code is probably based on an old datahseet:

Because that's just wrong...Looking at hwSleep for AVR it looks like it's just using attachInterrupt with the passed through mode. I'll test later because in fact I'm working on a project with a MPR121 touch controller that wakes up my Pro Mini on FALLING so I change it to CHANGE and see what happens...

Anyhow, @kk02067 I'd use INT0/1 pins if you can...also, just measure the current consumption und unplug the nrf to see how much it changes. My mentioned MPR121 project consumes about 0.5-0.9mA in sleep and ~18mA in awake (MPR121+Pro Mini+nrf) just to give you some ballpark numbers. Consumption went to 5mA with nrf unplugged.

Sorry for OT but I am a bit confused, doesn't support sleep wakeups on pin changes? I guess you mean something else then?

/**
   * Sleep (PowerDownMode) the MCU and radio. Wake up on timer or pin change.
   * See: http://arduino.cc/en/Reference/attachInterrupt for details on modes and which pin
   * is assigned to what interrupt. On Nano/Pro Mini: 0=Pin2, 1=Pin3
   * @param interrupt Interrupt that should trigger the wakeup
   * @param mode RISING, FALLING, CHANGE
   * @param sleepingMS Number of milliseconds to sleep or 0 to sleep forever
   * @param smartSleep Set True if sending heartbeat and process incoming messages before going to sleep
   * @return Interrupt number if wake up was triggered by pin change, @ref MY_WAKE_UP_BY_TIMER if wake up was triggered by timer, @ref MY_SLEEP_NOT_POSSIBLE if sleep was not possible (e.g. ongoing FW update)
   */
int8_t sleep(const uint8_t interrupt, const uint8_t mode, const uint32_t sleepingMS = 0,const bool smartSleep = false);

@AWI Ha, I forgot about that...I remembered that you actually need a minimum load on the output of the switching regulator for it to even run. I created a spreadsheet just taking into account the quiescent currents and assuming 70% effciency for the lm2596 (a "bit" optimistic. Datasheet says 80% at 3A load for 12V-5V operation). Quiescent current for the LM2596 is much higher.

Considering the mini pro takes about 12-20mA running, I am sure to opt for the 7805 or LM317 from now on ;) (If there is nothing else drawing current). I think nano etc are comparable but the FTDI USB to serial converter probably adds some current that the mini pro is missing.

0_1491471734938_analysis7805.xlsx

@AWI Was about to say that ;) For a hobbyist it doesn't matter that much but switching regulators are quite nasty when it comes to EMI.

@gohan: A good rule of thumb is to assume that the voltage difference from input to output of the linear regulator will be converted to heat. So if you have a high current application or a high voltage difference a switching regulator is better. In case of running an Arduino (let's say it consumes 80mA@5V which is quite high) it's negligible: P=U*I=(12-5)*0.08=0.5W which should be dissipated without heatsink easily.

edit: ah you just answered yourself ;D

@micah @gohan Yeah I could imagine nasty spikes from a cheap power supply can fry the regulator. I still find an LM2596 overpowered for this. At least take a 7805 :P

@gohan: I understand but what's the incentive? It's more easy to plug the Arduino via USB and do serial gateway than fiddling with MQTT and network stuff.