Topics created by Soloam

I agree you have centered all the critical points: Ordering a pcb, all components and then soldering it is quite a barrier for "ordinary" people. Absolutely true! In fact my plan is to start a second Kickstarter campaign to sell some pre-assembled boards, if there are enough people interested and the feedback form the first campaign (not assembled pcb) is good. I have opened the d-diot website Friday, so the entire project is still a baby and I don't have a clear view of the next steps . In any case a final goal could be also a full finished product (case + board + Raspberry). For the ordinary user this will mean "plug in, take out your smartphone and play" What keeps you from having it open source and still sell assembled boards? In this moment only one "irrational fear" (please note the "" ).... loosing the possibility to keep the project sustainable and self-sufficient from an economical point of view (chinese clone, in other words). But I agree opening the hardware will improve and speed up the development and, at the end, the quality of the final product. The open source model works and this is a a fact (see Linux and Arduino). I think that a viable solution for me in this moment is to open at least the schematics; I'm evaluating this possibility from two days. 90% would buy a pre-made board from you. Yes I believe that too. Unfortunately the final price of a fully assembled board will be not so low, probably around 40-50€ (estimated), because today the assembly is not so cheap as the pcb manufacturing and the value of the components + radio modules is around 25€ (see here). So I prefer to keep also the DIY way open. Of course the price of a fully assembled board will drop with a massive production. Sorry for the long post but I think that there are great possibilities around the open source home automation, which is a good thing also for privacy and security, especially now in the cloud era, but, in my opinion, the problem is that the various projects (and there are many!) are fragmented and not integrated in a simple and plug&play solution for the normal user. In fact d-diot is born from this consideration. I have not talked about the other ideas / consideration to improve the experience of the others makers and that can generate some incomes to support the development, but for this post, I have already wasted enough bits with my bla bla bla, so I will proceed, if some other people are interested.

Thank you @David-Muller

@soloam If you changed the optimistic setting, actuators will have assumed state and this will show in the ui as two different buttons for on and off. I recommend to not use optimistic setting, but instead feedback the new state to home assistant.

I didn't see that before, thanks

@jkandasa actually, MYSBootloader does not implement ACK handling (due to space constraints), but online FOTA does.

@soloam OK, so in the end this seems to be a problem related to that particular controller software. Imo it would be better to address this issue by enhancing the controller software towards a more constant handling of added infos from user side like renaming devices rather than using the limited space on the mcu to store info not needed by other controllers.

@soloam good to hear! Thanks for reporting back

Thanks I'll take a look

I have a similar situation: my house had manually operated roller shutters, where you had to keep the button pressed to open or close them. Importantly when the end stop is reached, the motor is not powered in the moving direction anymore (probably some integrated reed contact or something). If this is the case for you, my solution will work well: Just make a normal arduino relay (1 for every direction) and calibrate them with a timer. Then just make sure that you add some time for the opening direction (a few seconds), it will make sure that for every cycle any drift is compensated. This even worked for me when I had to reset the system with the rollers at a certain percentage => just move up and down a few times and it's ok again. In my system I have implemented the manual switches (which used to switch the 220V by connecting them with the 5V node source and switching dedicated input pins on the arduino. I have two nodes, one with 3 roller shutters and one with 1 shutter and 1 awning. (I think on the 3 up/down variant, there were not enough input pins for manual input, so I had all bound to one up-down switch). Here's my code (it has become somewhat messy, and if I remember correctly I changed from 100% open to 100% closed mode when changing from home assistant to openhab2): /** The MySensors Arduino library handles the wireless radio link and protocol between your home built sensors/actuators and HA controller of choice. The sensors forms a self healing radio network with optional repeaters. Each repeater and gateway builds a routing tables in EEPROM which keeps track of the network topology allowing messages to be routed to nodes. Created by Henrik Ekblad <henrik.ekblad@mysensors.org> Copyright (C) 2013-2015 Sensnology AB Full contributor list: https://github.com/mysensors/Arduino/graphs/contributors Documentation: http://www.mysensors.org Support Forum: http://forum.mysensors.org This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License version 2 as published by the Free Software Foundation. ******************************* REVISION HISTORY Version 0.4 - October 13, 2017 - Powerpenguin Added dedicated inputs for all manual switches (This is possible for 2 up/down actuators: D2-D5 relay, D9-D13 nRF24, A0-A3=D14-D17: switches) Version 0.3 - October 9, 2017 - PowerPenguin DESCRIPTION Based on Dimmable LED Light using PWM from Henrik Ekblad Simple control of window shades which are already motorised and don't provide any more feedback, i.e. we want to send a target percentage from the controller to the shade which then moves as tgt_percentage * time_to_fully_close In the first implementation we assume that the starting state is fully open, so some "drift" is to be expected? Or "overshoot" opening by a margin to make sure 100% corresponds to fully open? (yes: home assistant takes % open, not % closed) The sketch supports multiple blinds, i.e. multiple relays connected to the arduino. There are two relays per blind, for up/down respectively Also, additional pins are read for a push-button, to manually give the up or down signal (will start/stop moving one or covers simultaneously, based on btcidmap[]) To avoid the relays coils from being powered in normal operation, and most relays are active low, high/low has been reversed (so high unless activated) (better buy active high relays!) The code has become somewhat messy, better to use interrupt on manual switch? Event based? */ // Enable debug prints to serial monitor #define MY_DEBUG // Enable and select radio type attached #define MY_RADIO_NRF24 //#define MY_RADIO_RFM69 #include <MySensors.h> #define SN "WindowShades" #define SV "0.4" #define PIN_BASE 2 // first of the Arduino pins attached to relay #define LOOP_DELAY 950 // loop delay in ms #define LOOP_DELAY_SMALL 30 // delay between transmissions for different sensors #define PIN_BASEA 14 // base of the analog pins to be used as digital input #define NCOV 2 // number of covers, each have an up and down relay; maximum is half the number of available digital i/o pins #define NCSW 2 // number of pairs (up/down) of manual override switches enum coverstates_enum {UP, DOWN, STOPPED}; static bool btmanup_pressed[NCSW]; static bool btmandn_pressed[NCSW]; bool initialValueSent[NCOV]; static int8_t currentLevel[NCOV]; static int8_t targetLevel[NCOV]; static int8_t time_open[NCOV]; static int8_t time_close[NCOV]; static unsigned long tstart[NCOV]; static int8_t lstart[NCOV]; // the manual button vs. CID mapping has to be specified manually, since sometimes we want one manual button to control more channels static int8_t btcidmap[NCOV] = {0, 1}; static coverstates_enum state[NCOV]; // number of values must be NCOV MyMessage msgPct[NCOV]; void setup() { // initialise all child actuators and related vars for (int8_t cid = 0; cid < NCOV; cid++) { msgPct[cid] = MyMessage(cid, V_PERCENTAGE); pinMode(PIN_BASE + 2 * cid, OUTPUT); pinMode(PIN_BASE + 2 * cid + 1, OUTPUT); state[cid] = STOPPED; initialValueSent[cid] = false; currentLevel[cid] = 100; targetLevel[cid] = 100; time_open[cid] = 29; // seconds to open, if not the same for all covers specify independently time_close[cid] = 27; // seconds to close } // specify times independently if not the same for all covers below time_close[0] = 40; time_open[0] = time_close[0] + 3; // overshoot to make sure we open completely, motor stops anyway time_close[1] = 26; time_open[1] = time_close[1] + 3; // overshoot to make sure we open completely, motor stops anyway // time_close[2] = 22; // time_open[2] = time_close[2] + 3; // overshoot to make sure we open completely, motor stops anyway for (int8_t i = 0; i < NCSW; i++) { pinMode(PIN_BASEA + 2 * i, OUTPUT); pinMode(PIN_BASE + 2 * i + 1, OUTPUT); btmanup_pressed[i] = false; btmandn_pressed[i] = false; } } void presentation() { // Register the Cover with the controller sendSketchInfo(SN, SV); for (int cid = 0; cid < NCOV; cid++) { present(cid, S_COVER); } } void loop() { int8_t cid; int8_t delta; for (cid = 0; cid < NCOV; cid++) { if (!initialValueSent[cid]) { Serial.println("Sending initial value"); send(msgPct[cid].set(currentLevel[cid])); Serial.println("Requesting initial value from controller"); request(cid, V_PERCENTAGE); wait(LOOP_DELAY); // extra delay to give more time for initial handshake } else { // toggle moving if manual button pressed (since we arrive heare about once a second, // we don't need debounce, but we need to press the button up to 1 s to have a reaction btmanup_pressed[btcidmap[cid]] = (bool)digitalRead(PIN_BASEA + 2 * btcidmap[cid]); btmandn_pressed[btcidmap[cid]] = (bool)digitalRead(PIN_BASEA + 2 * btcidmap[cid] + 1); // if both pressed, reset (no reaction) if (btmanup_pressed[btcidmap[cid]] && btmandn_pressed[btcidmap[cid]]) btmanup_pressed[btcidmap[cid]] = btmandn_pressed[btcidmap[cid]] = false; if (btmanup_pressed[btcidmap[cid]]) { btmanup_pressed[btcidmap[cid]] = false; if (state[cid] == STOPPED) { targetLevel[cid] = 100; } else { // if already moving, then stop by setting target to current currentLevel[cid]; } } if (btmandn_pressed[btcidmap[cid]]) { btmandn_pressed[btcidmap[cid]] = false; if (state[cid] == STOPPED) { // if (reference) not moving, then make go up targetLevel[cid] = 0; } else { // if already moving, then stop by setting target to current currentLevel[cid]; } } if (currentLevel[cid] > targetLevel[cid]) { // move down (close) => means decreasing pct! if (state[cid] != DOWN) { // we just started going down state[cid] = DOWN; tstart[cid] = millis(); lstart[cid] = currentLevel[cid]; // mstotgt[cid] = (currentLevel[cid] - targetLevel[cid]) * 10 * time_close[cid]; // remaining time to target } digitalWrite(PIN_BASE + 2 * cid, 0); // down pin digitalWrite(PIN_BASE + 2 * cid + 1, 1); // up pin // level change over elpased time, don't exceed targetLevel (will lead to control settle behaviour) currentLevel[cid] = max(lstart[cid] - (millis() - tstart[cid]) / (10 * time_close[cid]), targetLevel[cid]); Serial.print("Sending percentage feedback..."); Serial.println(currentLevel[cid]); send(msgPct[cid].set(currentLevel[cid])); } else if (currentLevel[cid] < targetLevel[cid]) { // move up (open) if (state[cid] != UP) { // we just started going up state[cid] = UP; tstart[cid] = millis(); lstart[cid] = currentLevel[cid]; // mstotgt[cid] = (currentLevel[cid] - targetLevel[cid]) * 10 * time_close[cid]; // remaining time to target } digitalWrite(PIN_BASE + 2 * cid, 1); // down pin digitalWrite(PIN_BASE + 2 * cid + 1, 0); // up pin // level change over elpased time, don't exceed targetLevel (will lead to control settle behaviour) currentLevel[cid] = min(lstart[cid] + (millis() - tstart[cid]) / (10 * time_open[cid]), targetLevel[cid]); Serial.print("Sending percentage feedback..."); Serial.println(currentLevel[cid]); send(msgPct[cid].set(currentLevel[cid])); } else if (currentLevel[cid] == targetLevel[cid]) { // we always stop when the level is reached // we don't change the state here, because we want to send a final level value to the controller first digitalWrite(PIN_BASE + 2 * cid, 1); // down pin digitalWrite(PIN_BASE + 2 * cid + 1, 1); // up pin if (state[cid] != STOPPED) send(msgPct[cid].set(currentLevel[cid])); state[cid] = STOPPED; } // Serial.println("Sending current level to controller"); // Serial.println(currentLevel[cid]); // Serial.println("targetLevel = "); // Serial.println(targetLevel[cid]); // if (state[cid] != STOPPED) send(msgPct[cid].set(currentLevel[cid])); // send current estimated percentage back to gateway, until stopped state reached // if (currentLevel[cid] != targetLevel[cid]) state[cid] = STOPPED; } wait(LOOP_DELAY_SMALL); } wait(LOOP_DELAY); } void receive(const MyMessage &message) { // the message sets the target value for each sensor. // as long as the target is not reached, the approriate relay pin is kept high // and the controller is informed every LOOP_DELAY ms about the progress // Serial.println("Message received from gateway (cid):"); // Serial.println(message.sensor); if (message.isAck()) { Serial.println("This is an ack from gateway"); } switch (message.type) { case V_PERCENTAGE: if (!initialValueSent[message.sensor]) { Serial.println("Receiving initial value from controller"); initialValueSent[message.sensor] = true; } targetLevel[message.sensor] = atoi(message.data); targetLevel[message.sensor] = targetLevel[message.sensor] > 100 ? 100 : targetLevel[message.sensor]; targetLevel[message.sensor] = targetLevel[message.sensor] < 0 ? 0 : targetLevel[message.sensor]; Serial.println("Received V_PERCENTAGE from controller"); break; case V_UP: targetLevel[message.sensor] = 100; Serial.println("Received V_UP from controller"); break; case V_DOWN: targetLevel[message.sensor] = 0; Serial.println("Received V_DOWN from controller"); break; case V_STOP: Serial.println("Received V_STOP from controller"); targetLevel[message.sensor] = currentLevel[message.sensor]; break; } } Good luck!

Just to end and close the topic, @tekka great work on the Bootloader and @jkandasa great work on MyController... Thank you

The problem is that the boards.txt is declaring the use of the tool avrdude, in the sketchbook the IDE is not able to find the avrdude, so the error. That's what you get when you mix a Arduino noob with a linux noob Thank You

@gohan said in Nrf24l01 with router antenna: You can make a directional antenna to go farther in a specific direction with less power..... Transmission power input can indeed be reduced with any higher gain antenna, even going from a coiled 1/4 to a Dipole can reduce power input to advantage. However, directional and omni-directional arrangements need not be mutually exclusive. In the majority of cases omni-directional antennae are simple to make and quite adequate for most case uses, particularly for sub GHz. In the vast majority of arrangements, the gateway will be physically central to the nodes so has to be omni-directional. It is at the radial nodes where a directional antenna can provide benefits of larger signal or reduced power input, as it only has one direction to aim at, the Gateway. A directional antenna is in simplistic terms an omni-directional antenna with reflectors and directors, but it is the reflector which is crucial. Mounting an omni-directional with a metal reflective surface behind it will squeeze the radiation and receive lobe in the opposite direction, be it the metal siding on a shed, a biscuit tin lid, or a simple trough reflector. Easy enough to make without resorting to higher battery consumption... link text

Mine usually tops out at about 30%. What is the output of the following?? $ java -version $ javac -version

@Soloam that's some great code, mind if I copy it for my nodes? // Ah, wait, that's blocking code isn't it. Not technically, with the wait() function. But it would stop the rest of my node from running until the process is complete?

Not only a genius, the founding father of the SenseBender series Himself

Hi @Soloam, not sure if you managed to solve your problem. I would recommend using Mosquitto MQTT broker open source or Pro version since they both support all MQTT QoS levels (including QoS 0, QoS 1, QoS 2).

@monte yeah, I will have to go back to that thread again and read it thoroughly if I ever need to implement something that requires reliable messages.

@soloam you can connect the ftdi and the charger at the same time. Just skip connecting Vcc from the ftdi.

Thank you for your replay. My main doubt was the client-id, I didn't understand if it was a unic name or the GW client-id. You answered my question. Thank You for your help

I have 2 controllers connected to 2 ethernet gateways running all on the same rpi. I don't know really what happens to the mqtt broker if it gets clogged with a queue of undeliverable messages, you have to debug it and see if the mqtt grows too much

Actually, in my experience plain old MQTT is difficult to connect to. There is a Git issue to create (also) an MQTT output that is simplified or follows standards. https://github.com/mysensors/MySensors/issues/1212

That is it! Thank you!

Just one final question... is the approach to MQTT correct or should I stick with simple Ethernet? I was planning on using OpenHab or Home Assistant. Thank You all

Wire Length? Way is this important? The problem was solved soldering te 2 resistors! The cable length is a normal small cable going to the router

@Soloam Hello looks like a great board. Any progress on the Switch board? //Henrik

I'm studding the possibility of making the speech recognition with a raspberry pi zero and google stt api! Then I would publish a MQTT string to control my MySensors with OpenHab. The main problem of this approach is the delay time between the request and the action, because the audio must be translated by google and return to analises.

Thank you all for the fast response! Best Regards

@soloam Yes, the state makes the difference of course. Because you had used command for all definitions I assumed that your intention was to also send in a command from outside of Openhab to control the light. Glad you found a solution.