Posts made by brendanl

Maybe this could help?
https://forum.mysensors.org/topic/4077/gatewayw5100mqttclient-my_signing_soft-development-branch-atmega328-nano-sketch-too-large

Opto isolated from existing Rinnai controls and feedback.

All documented at https://techconz.com/smart-home/rinnai-gas-heater-ftr557/

Still to establish some OpenHAB rules for it, but will likely be Mon-Fri @ 7am when < 11 degrees outside, turn on.

Over the weekend I hacked the previously battery powered Minecraft lights in the Minecraft bedroom (doesn't everyone have one?). Now there's no more replacing batteries and OpenHAB controls include On, Off, Brightness and Flame Flicker.

This is the reason I was asking about establishing power distribution in the attic. I've decided to distribute 12v and drop to 5 or 3.3 only as needed.

More info and video: https://techconz.com/smart-home/minecraft-lights/

@wallyllama Nice answer - thanks very much.

I'm going to go with a central power distribution point and send out 12v to any nodes that need powering. Each node will have a buck and drop whatever voltage they receive by that point, down to 5v. This way I avoid any voltage drop issues that could occur.

It also gives me a single & scalable power source location and nodes close to their activity & still fulfilling their mesh roles and responsibilities!

I like the @petewill setup, but will probably establish it using something like these: https://www.aliexpress.com/item/Free-shipping-1pcs-9-road-output-switching-power-supply-wiring-board-current-shunt-board-wit-fuse/693330771.html

I was also thinking of going one step further with something like: https://www.aliexpress.com/item/9CH-DC-12V-15A-Switching-Power-Supply-With-Box-180W-Monitor-Camera-12V-Power-Transformer/32602759262.html but I'm not sure just how much to trust these? At least with just the first distribution board, I can power it with some old wall-worts initially (appreciate less power capacity). If anyone has anything good to say about the aliexpress switching power supplies, I may still consider.

Cheers

Thanks guys for the info. In addition to distributing the power to the remote nodes, what do people think about centralizing the nodes and only spreading out the wires to the sensors/actuators? Again, voltage drop could be an issue, but I'm more thinking about the 'concept' of centralizing components of the mesh network vs distributing. It sounds contradictory and I fully appreciate different approaches to different needs etc. I guess I'm perhaps after theoretical feedback?

I currently have several sensors throughout the house collecting information and controlling various things. All the sensors to date have been independently powered where they are located.

I’m now thinking of dropping some relays in walls and perhaps some low power lighting and am contemplating the following approaches to distribution:

• Nodes continue to be independently powered where they are located. Pro is isolation, con is more 240v to 5v convertors and needing to put these somewhere (in wall etc).
• I run a single 5v or perhaps a 12v wire around the attic and power the distributed nodes from this. Pro is less 240v convertors & safe distributed power levels, con is potential voltage and current supply issues as node numbers increase. Perhaps I distribute 48v to compensate?
• Nodes are centralised somewhere and only the feed to the relays etc are distributed. Pros are easier to scale power requirements (add more transformers in one place) & easier to re-flash arduinos if necessary (I’m not using OTA). Cons is fiddly build to make it look and function nice and more wires being distributed everywhere in the attic. And does centralising nodes complement or contradict the MySensor mesh network approach??

Appreciate people’s thoughts and their own experiences. And if anyone has seen some nice gear that would help with any of the builds, I would be interested. Otherwise it’s cellotape for the wires and pieces of wood to make a box

@gohan
If you're talking about my build, thanks for the feedback and I've just made it clearer on the page now. 5V & Gnd for the node are from the Daikin units IR Sensor. Careful though, short this and you'll be tracking down a fuse to fix on the header units main board.

Hi
Feel free to check out my recent Daikin Overhaul. Though please note the voltage danger and liability statements :). I'm happy to help out if I can.
Cheers

Well I've just got mine working again. I'm putting it down to the birds not just crossing, but circulating for the last couple of weeks!

After the work last night, I moved my Gateway into the same room as my node on the breadboard in order to swap radios and it instantly became more responsive (much less NACKs & much less randomness on signed communication). I continued swapping radios etc to at least demonstrate consistency/working radios, but the location improvement alone was a Big Clue!

I have a NRF24L with the external aerial on the gateway, so was always expecting it to continue performing well regardless of what was around it. In my case though it was sitting above a metal 19" network patch panel & right next to a running laptop. Inside the patch panel as well as numerous runs of Cat6, is a 24port switch and a 8 port POE switch. Fair enough, plenty of interference potential, but I don't recall changing any of that recently (for it to just drop out).

Anyway, whether it's a combination of things, wriggling some wires, resetting some radios in their sockets etc or just now positioning the Gateway further from all the metal, we're back in business.

I agree, nothing wrong with the software, but perhaps somewhat sensitive on the environmental factors.

Thanks guys and good luck with the remainder of yours @sineverba

@sineverba said in Software signing suddenly stop working:

MY_SIGNING_REQUEST_SIG

Interestingly I'm working through a very similar issue myself just now. The garage door opener just stopped working a few days ago.

I've pulled the Pro Mini out and onto a breadboard and have been doing the following this evening:

• Updated it to 2.1.1 from 2.0.0 beta (no improvements)
• Re applied the Security Personalizer / soft HMAC Key with the 2.1.1 core (no difference, nor was I expecting that)
• Added #define MY_DEBUG_VERBOSE_SIGNING
• Added #define MY_SIGNING_SOFT_RANDOMSEED_PIN A0 (I never had this line, but it made no difference)
• Added a capacitor across the NRF24 (no difference)
• Added additional debug statements to MyTransport.cpp but haven't discovered anything yet.
• Disabled MY_SIGNING_SOFT (immediately fixes it, but I don't want that)

My experience is that the messages either never get received (no trace output) or the output ends at "Transmitted nonce". Randomly, it will work.

It used to work just fine and I'm reluctant to drop the signing. So I'm definitely interested in how you get along and I'll update too if I get my end sorted.

Cheers

I've started documenting the MySensors sensors that I have in my house for my own record keeping and sharing.

So far this includes:

• Ethernet Gateway
• Garage Door opener
• Hacked Daikin Heatpumps
• Tropical Fish tank
• TV Back light
• Hacked Passive InfraRed (PIR) sensor
• Power usage sensor
• Water meter sensor
• Cabinet RGB Light

The Controller is OpenHAB and I'll be posting all this info as well. Details: https://techconz.com/smart-home/

I'm happy to answer questions and provide more information. My documentation is a work in progress, but I'm trying to get through it pretty quickly.

Thanks go to MySensors and all the good folk on the forums for helping along the way with making our house rather cool!

Good to know - thanks for pointing that out.

Thanks for that. However, the above output was at the sensor end, not the gateway. I've got all I was going to get out of the gateway.

Interestingly the HMAC reported above is not what was stored and reported by SecurityPersonalizer - I had checked before I posted. It must be HMAC along with some other stuff - regardless, I've changed my HMACs now in case anyone in New Zealand felt so inclined to reverse engineer things.

cheers

@mfalkvidd thanks again for your thoughts.

I wasn't having much luck reducing things, so came across another cunning plan. Initial info here https://bigdanzblog.wordpress.com/2014/10/23/installing-the-optiboot-loader-on-an-arudino-nano-to-fix-the-watch-dog-timer-wdt-issue

Turn Nano into Uno to free-up more memory (load optiboot bootloader)

1. Use Uno as programmer – see here: https://learn.sparkfun.com/tutorials/installing-an-arduino-bootloader
2. Upload Examples/AudrinoISP sketch to Uno
3. Select type of Board Nano needs to be e.g. Adruino/Genuino Uno
4. Select Tools/Burn Bootloader – this loads Uno bootloader into Nano. Behind the scenes, this bootloader is C:\Program Files (x86)\Arduino\hardware\arduino\avr\bootloaders\optiboot\optiboot_atmega328.hex (at least for my IDE setup)

Nano now has 32,256 bytes free instead of 30,720. Plenty enough to store the 31,070 my MQTT/SoftSPI/SigningSoft gateway needs. And after re-running SecurityPersonalizer (because bootloading cleared EEPROM), Signing is now working:

Signing backend: ATSHA204Soft
SHA256: EBB61F82572BBB42676ADA13705C918B05588F926D3E15F58800000000000000
Transmittng nonce
send: 46-46-0-0 s=255,c=3,t=17,pt=6,l=25,sg=0,st=ok:EBB61F82572BBB42676ADA13705C918B05588F926D3E15F588
Signature in message: 0194DB798EFE5B3543EEA0381D7817591E6E5A279A28FC13
Message to process: 002E0E00020131
Current nonce: EBB61F82572BBB42676ADA13705C918B05588F926D3E15F588AAAAAAAAAAAAAA
HMAC: A794DB798EFE5B3543EEA0381D7817591E6E5A279A28FC13A7716480D1820181
Signature OK
read: 0-0-46 s=1,c=0,t=2,pt=0,l=1,sg=0:1

Fantastic!

Thanks. As mentioned, sketch is pretty much stock. I'll have a poke around the core code and see if I can't remove something I'm not using - though I'm expecting 'optional' features to be configurable and defaulted to off, so as mentioned, it will take some creativity.

cheers

#include <SPI.h>


#define MY_SIGNING_SOFT 

// Enable debug prints to serial monitor
//#define MY_DEBUG 

// Enables and select radio type (if attached)
#define MY_RADIO_NRF24
//#define MY_RADIO_RFM69

#define MY_GATEWAY_MQTT_CLIENT

// Set this nodes subscripe and publish topic prefix
#define MY_MQTT_PUBLISH_TOPIC_PREFIX "mygateway1-out"
#define MY_MQTT_SUBSCRIBE_TOPIC_PREFIX "mygateway1-in"

// Set MQTT client id
#define MY_MQTT_CLIENT_ID "mysensors-1"

// W5100 Ethernet module SPI enable (optional if using a shield/module that manages SPI_EN signal)
//#define MY_W5100_SPI_EN 4  

// Enable Soft SPI for NRF radio (note different radio wiring is required)
// The W5100 ethernet module seems to have a hard time co-operate with 
// radio on the same spi bus.
#if !defined(MY_W5100_SPI_EN) && !defined(ARDUINO_ARCH_SAMD)
  #define MY_SOFTSPI
  #define MY_SOFT_SPI_SCK_PIN 14
  #define MY_SOFT_SPI_MISO_PIN 16
  #define MY_SOFT_SPI_MOSI_PIN 15
#endif  

// When W5100 is connected we have to move CE/CSN pins for NRF radio
#define MY_RF24_CE_PIN 5
#define MY_RF24_CS_PIN 6

// Enable these if your MQTT broker requires usenrame/password
//#define MY_MQTT_USER "username"
//#define MY_MQTT_PASSWORD "password"

// Enable MY_IP_ADDRESS here if you want a static ip address (no DHCP)
#define MY_IP_ADDRESS 192,168,1,150

// If using static ip you need to define Gateway and Subnet address as well
#define MY_IP_GATEWAY_ADDRESS 192,168,1,254
#define MY_IP_SUBNET_ADDRESS 255,255,255,0

// MQTT broker ip address or url. Define one or the other. 
//#define MY_CONTROLLER_URL_ADDRESS "m20.cloudmqtt.com"
#define MY_CONTROLLER_IP_ADDRESS 192, 168, 1, 100

// The MQTT broker port to to open 
#define MY_PORT 1883      

 /*
// Flash leds on rx/tx/err
#define MY_LEDS_BLINKING_FEATURE
// Set blinking period
#define MY_DEFAULT_LED_BLINK_PERIOD 300

// Enable inclusion mode
#define MY_INCLUSION_MODE_FEATURE
// Enable Inclusion mode button on gateway
#define MY_INCLUSION_BUTTON_FEATURE
// Set inclusion mode duration (in seconds)
#define MY_INCLUSION_MODE_DURATION 60 
// Digital pin used for inclusion mode button
#define MY_INCLUSION_MODE_BUTTON_PIN  3 

// Uncomment to override default HW configurations
//#define MY_DEFAULT_ERR_LED_PIN 16  // Error led pin
//#define MY_DEFAULT_RX_LED_PIN  16  // Receive led pin
//#define MY_DEFAULT_TX_LED_PIN  16  // the PCB, on board LED
*/

#include <Ethernet.h>
#include <MySensor.h>

void setup() { 
}

void presentation() {
  // Present locally attached sensors here    
}


void loop() {
  // Send locally attech sensors data here
}

Hi there

Firstly, thanks for all the great info and advice around the place. I've been quite active and successful on the build front since I started here a few weeks ago. Here's my gateway, a remote temp/switch sensor and a combo RGB controller and temp sensor/ir unit. With the exception of the ir stuff, all are working and connected to OpenHAB via Mosquitto.

The sensor currently under construction will be smartening up the garage door controller. For this, I'm coming back around and activating Signing. Trouble is, with adding #define MY_SIGNING_SOFT to the stock Dev branch GatewayW5100MQTTClient sketch, I'm getting "Sketch uses 31,070 bytes (101%) of program storage space. Maximum is 30,720 bytes." (MY_DEBUG has been commented out)

I've got all the HMAC personalization done and loaded into the gateway and the sensor. With the gateway missing the MY_SIGNING_SOFT, the sensor reports "Message is not signed, but it should have been! verify fail" when told to do something.

I can't figure out why the gateway is too large for the Nano. Besides configuring SoftSPI and the necessary network connectivity IPs (including a static one on the gateway), I've done nothing else to the sketch. The only hint that I'm not alone with this issue is this quote from Anticimex "Soft signing on master with a ethernet gw will not fit as master looks currently and on a AtMega328" This was here 4 months ago.

Can someone please verify that Soft signing is currently not possible with the MQTT Gateway on the Development branch (2.0.0-beta). If it should be possible, any ideas where I could have gone wrong? (appreciate this is a pretty open question)

Cheers