Actually yes, if you make an image from a SD card and you flash it back you get a system working at that previous state. I actually use dietpi that has a built in backup/restore feature that I already used few times and it even worked to restore to another RPI also running the same dietpi

Maybe 123d.circuits.io is a good alternative for MySensors users. It has an editor like Fritzing, which you can easily toggle to schematics view or PCB design. It is even able to simulate Arduino with running code! Quite impressive.

Serial: It probably works just fine, but I've always had a little trouble with serial devices on a Vera. UI7 Latest release: Yes, a disaster, but the previous version is good. ALTUI: Yes, it's excellent. Only difference UI5 vs. UI7 is the aforesaid house modes and the icons are a little different. MySensors plugin: I've modified it to be ALTUI friendly: currently it displays the IP address of the gateway, but I will add number of nodes and sensors - this seemed like the most useful information? [image: 1440665680174-mysensors-on-altui.jpg]

Hm, I just found a reference regarding the CH340 and 3.3v. From http://www.minikits.com.au/nano-v3.0b The Arduino Nano can be powered via the Mini-B USB connection, 6-20V unregulated external power supply (pin 30), or 5V regulated external power supply (pin 27). The power source is automatically selected to the highest voltage source. The CH340G chip on the Nano is only powered if the board is being powered over USB. As a result, when running on external (non-USB) power, the 3.3V output (which is supplied by the CH340 chip) is not available and the RX and TX LEDs will flicker if digital pins 0 or 1 are high. My question about using the 3.3v supply from the Nano for the nRF came from two use cases: Running with a 5v USB power supply sounds OK. But I was also thinking of running from a 12V supply in a case where 12V is used for relays and lights anyway. I was thinking to use the onboard 5V regulator for the Nano's uC, and the 3.3v supply for the radio. The quote sounds like the latter would not work - unless perhaps I bridged the 5V from the uC regulator to the USB 5v pin to activate the CH340 ? (Some more power, perhaps interference if I wanted to use the uC RX pin). Any knowledge or experience to share? One aside: Sometimes a regulator is spec'd up to 12v and sometimes a 12v supply is a little high. My thought was to insert a diode in line to drop a volt or so; this should give more margin, and also at least slightly reduce how much of the voltage/power has to be dropped & dissipated inside the linear regulator. As a side effect, it might help with accidental reversal of voltage. This is also my answer to someone who wanted to run an unregulated ardu pro mini off 4xAA alkaline.

Hi, on gateway I'm using a NRF24L01+PA+LNA and everything works fine if I use NRF24L01+ or SI24R1 on sensor side. If I replace NRF24L01+PA+LNA with something different (NRF24L01+ or SI24R1 module) the communication does not work...

I finally made them work :) I was not using the right clock for programming, 16MHz instead of 8MHz... Thanks @AWI ;)

I'm thinking of 4 PIR sensors (at each end of the two aisles). And I was thinking of a reed switch at the top of the garage door opening, and one at the door into the house. And the most convenient location for the relays controlling the lights is still a 7th location. I could put 7 wireless nodes into the garage, but then I have to run power to all of them - if 5v we still have the same long wire issues, if 120VAC then I need 7 power supplies. And the local control now involves passing messages between nodes rather than just sensing input pins and controlling output pins on the same uC. The cables supply power to the RF enabled nodes will have the same length (whether DC or AC power) as the cables going to a simple sensor, and follow the same routes. So it would be possible to do that, but at considerable cost in money and time and complexity - compared to just running a three or 4 wire cable from the main node to a $2 PIR located 1o-20 feet away, if that can easily be made to work (perhaps with the addition of a couple of small, cheap passive components. I don't know if I do need to worry about inductance, capacitance, reflections etc - that's why I'm asking. These things aren't usually specified one way or the other - you kind of need some practical experience. If those are indeed killers that cannot be fixed with a couple of passives, then I may go to the "make every sensor a full node with AC power supply and distribute AC to them instead" route. But wouldn't it be nice if I can do a $2 easy fix instead? One data point - in the Do It Yourself Christamas lighting control community, they routinely get away with sending TTL or CMOS signals quite a ways from a control unit to an optoisolator input (which controls a Triac to form a SSR which does PWM dimming of an AC circuit). The signals are just a 120 Hz PWM signal but the edge timing is at 120Hz * 256 PWM divisions. You won't find much about driving a 50' cable from a TTL or CMOS output in the datasheets, but it works in this application! It would not work if you were sending a 1 Mbps signal tho. So I have some hope that a PIR 20 feet down a cable may be able to pass back a quite usable logic signal, since it changes rather rarely. But I was hoping for some advice about the gotchas. Remember the sensors I've mentioned are magnetic reed switches, LDRs, and PIR sensors - only the latter needs power per se separate from the signal.

@ntruchsess Yes, know there is a bit of lacking documentation :flushed: Inclusion mode is optional for controller to make use of. Presentation messages is always passed to controller. If controller wants it can choose to only allow adding device while inclusion is running. If gateway should handle id-handout by itself we would also need some kind of reset/clear functionality in the serial protocol to free up ids etc. The id statuses must be stored in gateway eeprom. Handling multiple parallell retransmits automatically by gateway (and nodes) could make it impossible to run it on a ATMega329 [speculation]. But if you got some neat ideas I'm open for suggestions (or pull requests) . If you decide to help out with something please use the development-branch.

Here's another project which passes a fire detection to a Home Automation System, much as I'm suggesting: http://harizanov.com/2014/07/diy-internet-of-things-fire-alarm/ The idea I was exploring is including our other sensors in the same housing if possible, and also making the piezo speaker a controllable actuator within our network. I don't have a 120V interconnected system (sound nice tho), but that's a good option for detection for those who do. Another option for interfacing a Home Automation system with multiple networked alarms - like the battery powered First Alert OneLink system - would be decoding the 433 MHz signals passed between these alarms. That of course does not take advantage of "hiding" a MySensors multi-sensor node inside the housing of a smoke alarm, tho. I kind of like the option of not needing to explain what these new boxes are in every room - if the sensor nodes look like smoke alarms, nobody will even notice them. And if that's done by making them hidden additions inside real and still-functioning real smoke alarms, even better!

@Zeph said: Does the temperarture measruring node have to be written to look at the Sender field in the request, and make a send to that? Yes.

@Tang Gateway is not a sensor ;)

@daulagari said: Why not take the plug-in (partly) outside the Home Automation Controller X and make it a component between the Home Automation Controller X and the Gateway That's kind of what I proposed a while back - with the provision that I suggested that one option could include running on the same hardware as the gateway. The idea was indeed to abstract the MySensors wsn. Thanks for the pointers to OpenZwave and Zigbee as possible interface candidates (or inspirations).. That will take more study. Does anybody know how widely these interfaces are already implemented in Home Automation control software? For example, if we had an OpenZWave interface to the MySensors WSN, would we be able to easily connect may open and/or closed source HM contollers to it?

@hek said: A scene controller (in the z-wave world), usually just i a wall-control with multiple (on/off) buttons, Like light switches. A Scene controller is a device which can trigger one or more pre-defined Scenes. That part is fairly simple and straightforward. The question in this thread is "What is this 'Scene' that it can trigger?". So turning scene 1 on simply means turning the button 1 in its on-position. It's a pure actuator. I think that's too narrow. Many home automation systems define scenes in software, without any need for there to exist a wall mounted button device which triggers them. A scene can be triggered by time or by a threshold being met or whatever. One key question about the nature of a scene is whether it's an extended command - sort of a macro that invokes other commands, or a state based system which does something continuously for as long as it's in that state? What's the difference? Suppose a scene includes "set living-room-lamp to 50% and set thermostat to 25 degrees". (It could also turn lamps OFF or fully ON or raise the blinds or whatever). If a scene is a type of command macro system, then it's a one time set of commands to send, each of which can be freely overridden by the next command (eg: set living-room-lamp 0%) - from another scene or manually sent via the UI or whatever. Once the scene is triggered (set ON), it sends the commands once and is done - no followup. If a scene was a reporting state system, then after sending the initial commands, it would monitor the lamp and thermostat for changes. While the devices remain in the initially commanded state the Scene would report itself as ON. As soon as either device's state was changed (eg: by another command or scene) then the Scene would report its own state as OFF because the conditions is describes are no longer true. This is the default with Vera (With Vera, you can also select that the scene will report as activated "if ANY light is turned off", which makes no sense to me) If a scene was a controlling state system, then it would maintain the living room lamp at 50% and the thermostat to 25 degrees until the scene was commanded to be OFF, overriding any changes from other sources. All three concepts could be useful (tho the controling state approach would have problems if another controlling state scene set the same devices differently, so you'd need conflict resolution rules). However, as best I understand it, the Scene concept is usually the first or second of these; either a fire and forget collection of commands to send and then do nothing, or send and then monitor the same devices and report the scene active iff all of them are still in the desired state. Is that other people's understanding too? And in the general cross-system case, what is the effect of turning a Scene OFF? Suppose that before turning the scene on, the living-room-lamp was at 100%. The scene in question sets it to 50%. What is the effect of turning that Scene OFF? Should the lamp go back to 100%, remain unchanged (ie: 50% unless something else has changed it), or go to 0%? If a scene is a command macro, turning it OFF doesn't make much sense. If it was a controlling state system, then turning it off would mean ceasing to continually control the devices and letting other commands and macros change them. If it was a reporting state system it would mean ceasing to monitor the device states (if it had not already turned itself off after detecting some change).

@Zeph said: can you share the test program you used? You can find it at https://github.com/Yveaux/Arduino_fixpt

@Damme Hi, The node might handle the ID itself? I used the reference on the top of this page: http://www.mysensors.org/build/sensor_api What i'm trying to put in the example is for a S_TYPE to supply multiple V_TYPE'S and the possibility to have the same V_TYPES based on fixed positions defined by the example char array. Just because the current setup is working with S_TYPES and V_TYPES. I have not thought about multiple S_TYPE's of the same kind... good point..... But would this not just send multiple presentations like: gw.sendSensorPresentation(ID1, S_DOOR); gw.sendSensorPresentation(ID2, S_MOTION); Or am i wrong... ? I agree absolutely with what your saying and that everything that can be done with data handling like the metrics and grouping etc. should be done on the controller. The current setup where there is just one group level is from what i think quite clever, of course on controller side it can be discarded, but it gives a nice multiple single purpose, multi sensor setup. An example with S_TYPE "Door": With the possibility to announce in advance what kind of V_TYPES it can send, lets say: V_LOCK_STATUS at position 0 in the char array and V_OPEN_STATUS at position 1 in the char array (just made up). With the possibility to announce in this way it is possible to auto create this "door" device and will of course be a one time request. When handling the V_LOCK_STATUS data on controller side when mysensors would send, as current is the case, the V_LOCK_STATUS it can send the array position of this V_LOCK_STATUS. Because the controller knows in advance that position 0 is V_LOCK_STATUS it can bound to that. Yes it does complicate stuff more on controller side, in my case it would be a simple extra mapping. On the hardware side it would require the programmer to keep track of it's V_TYPE's position. The driver i'm currently writing does not care how a "device" is defined. It can handle a sensor node as a device where the S_TYPES are groups which can contain multiple V_TYPES. Or it can create a "device" based on the S_TYPE which contains the V_TYPES. My example builds further on @hek 's example, which would give me the opportunity and i think also others to automatically create multi-V_TYPE S_TYPE groups. Me myself is using the sketchname for keeping track of what type of node (sensor group in your view) it is. But this could be sensor ID0 reserved for this. Everyone is free to program whatever they want! You dont even have to use V_TYPE.. You could use this as an adress as well, so you can actually address 256x256 sensors on every node.. Today you could even present every ID with a S_TYPE (id 1+2+3+4 = S_WEATHER) and then just send data with ID and V_TYPE.. Let the controller keep track of eveything, this will pose a problem for me tough in my MQTT broker. I dont have the space of storing this type of data. So I'll be might start publishing the Presentation data, This data is just discarded of today. But because I know people using stuff are full of ideas they will work around this problem. With my example I tried to keep the current multi table setup in honor and it currently is the default way to build the sensor network. I think @hek 's example does help to advance the MySensors protocol. And at the moment people are inventing their own idea's with code modifications and change the protocol data position definitions, in which of course they are free to do, they break the default compatibility. P.S. I also think this thread could better me renamed to "Advancing MySensors" then "Generalizing MySensors" ;) because it is so extremely difficult or even impossible to generalize at this current moment with all those hundreds of protocols, data- and sensor definitions used. Also with MQTT there is no generalization because everyone is free to create their own hierarchy. But, eventually, i will be fine with any implementation, as long is i know about it :).

@funky81 See the link near the top of the (edited) original post, to a thread which follows up on this one. For board designs created by the community, that thread going to be more up to date (and it tracks some information about what's available). This thread was earlier, but lists commercial options as well, so it's still of some value. I'm thinking to let the other thread keep up with community designs, but if you know of a good commercial offering for our purposes, please leave a reply and I'll add it to the list here.

FYI, @Bandra hasn't been "online" for over a year.