Development

Topic can be closed - while I still don't understand why this 16x repetition was reproducible consistently between these nodes and always only affected the third packet, it's now no longer reproducible and for now I'll just assume it has been a connectivity issue (even if nodes were sitting with <1m distance and nothing changed) [image: upload-3db49ba5-e7d0-4d9d-bb4b-32abb12ed966.JPG]

Nice! I'll have a look at the details later - thanks for the link! From a brief first look it appears that they can't fit the code into the bootloader which is why the main firmware downloads the new firmware to an external flash first and then the bootloader picks it up from the external flash and loads it into the internal flash. I personally don't like that approach for two reasons: need for additional hardware on every node just for OTA bootloading (external flash) less fail-save: with the bootloader executing the download you can always refresh a node even if the actual firmware has a bug that prevents it from working properly (worst case with a power-cycle to activate the bootloader). With the main firmware executing the download you would need to connect an ISP and locally program either the external flash memory or the AVR directly.

@Yveaux said: I think we could drop the protocol version number and use a full byte for command type. When, in the future, a command gets extended we can just reserve a new command-number for it. All existing applications will only recognize the old command-number and ignore the new one. As @zeph already pointed out this allows for more efficient usage of the 8 bits and a new version will not immediately disqualify an onld node completely as it will stil listen & respond to old commands. The value of having defined groups of command associated with a given protocol version is that you can get a pretty good idea of what a node will understand (or send). The first approach was to have some fixed number of bits for a protocol id, and some number for command-within-protocol (like 8+8 or 5+3 or whatever). I'm glad you see the advantages of adding command codes sequentially instead, especially if we are using one byte. I was suggesting that a given protocol version define a contiguous range of commands (plus some universal ones at the beginning of the codes). One caveat was that the "current protocol version" would be allowed to add new commands at the end of the sequence - the "last command allowed in this version" doesn't get frozen until a version is superceded by another one. Any given node need only understand the universal commands plus the range corresponding to the protocol version it was written to. So each version has the common universal commands plus a non-overlapping range of command specific to this version. The disadvantage is that you may have to redefine new command codes for commonly needed commands like "set value" every time you move to the next version. So in the first version, command 4 might be set (part of range 3..9). Then in the next version with commands (10..17) we have to define a new "set value" within that range, maybe code 11. Nodes implementing the second version only understand commands 0..2 (universal) and 10..17, they have no need to understand version one commands 3..9. A gateway would not expect a version 2 node to understand command 6. The hub could ask the node for the start and end of the range of commands it can accept. === One variant, which you are suggesting I think, is to ignore versoin based commadn code sub-ranges and just keep all commands allowable to all nodes. This has the advantage that "Set value" command 4 (in the above example) can continue to be used "forever", and not need to be reallocated code 11 to fit within the new version's range. But it may over time cause fragmentation or bloat - either we carry around the code to handle all commands (eg: 1.3 and 1.4 both), or the set of commands allowed once you switch to a new protocol version is non-contiguous (it contains some but not all commands from the older protocol version). I actually considered this, and the possibility of having the node respond to "what commands can you handle" with a bitmap instead of a start and end value, but decided that was getting too complicated. That was just my judgement call tho. (If you can correctly anticpate this kind of command in the "universal commands" that are part of all versions, the issue goes away. In the first appraoch, maybe "set value" is command 2 and globally available, not needing to be allocated a code in each versions's code range) But sometimes your concept changes more than you anticipated and "set value" might need to become a new command type in newer protocols). Deciding among these options depends somewhat on one's philosophy of where configuration information should be stored - in the nodes or in the hub. There are many answers to this question at different granularities. If you accept the concept of storing much config on the hub, then another approach emerges: each node can use a basic common protocol to report on first connecting what version of the full protocol it implements that per-node protocol version is stored in the hub the hub has bitmaps or tables of what command codes work for each protocol version it understands if the hub understands more than one version, it can communicate with nodes using any of those versions In this case, you don't make every packet include an explicit (fixed bits allocated) or implicit (code range) protocol version. But the hub could still know which commands work and don't work for any given node.

@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

Will try to add some more build instructions (for the new sensors) when 1.4 doc is released. The build pages can't really account for all module-variants out there ;) You always have to double check the pin order.

@scurb This looks very interesting and my factor now to save me from having to create my own :-). I have been planning to do the same thing (although maybe on a smaller software scale) by writing a simple Python server that would pull serial packets off of a gateway arduino (either running mysensors or something I write myself) and pipe this through MQTT to openHAB. I have two questions: How do you interface with a sensor network? Do you go through a serial connection to read the serial packet format (a,b,c,d)? I see several implementations that put the mqtt client directly on the Arduino, but it seems much cheaper for me to just plug it into a USB port to get a virtual serial port instead of investing in a separate ethernet shield :-) How does an item configurations look like for a switch in openHAB? I'm looking to build a toggle switch which toggles light on or off every time it is activated, and I cannot really understand how to configure the switch to allow this behaviour for an mqtt input. Feel free to take the second question with me directly since this might not be very interesting to the others in the forum :-)

Im install the gateway sketch and Yes if i put.the.command.in the serial monitor work turning on off a led in the sensor i have but without a 0 for ack like this "2;1;1;3;2;1\n" Im use the example this "echo " (command)\n" > comXX and this config mode com[NUMBER] BAUD=115200 PARITY=n DATA=8 STOP=1

I don't know why you use a telay. Look at thr watermeter code, it uses the pattern I described above

That's part of what brought me here actually - I was following (and mildly helping with) TMRH20's version of the library and I saw that this project was using it when scanning for forks of that.

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

@petewill said: Ok, looks like I was wrong again. Turns out was a bad wire (or wires) connecting the radio to the Mega. Either that or the Mega has some bad connections. Anyway, I switched out the wires and all is working again (for now). Loose wires are a bear to find at times - you do something (like adding a cap) and you think you fixed it. Then for no good reason the problem comes back. Been there.

@Yveaux Yes, example messages. Something like that - i have temperature from dht22 on one node, and i want to send this value to example node with radio id 2. Second thing, how to pick this value on radio node with id 2?

serial-usb adapter?

@BulldogLowell One follow-up question, how do I know what commands vera will send to the sensor or what commands the sensor will send back for a given SENSOR_TYPE. e.g. will it send V_DIMMER or V_DOWN etc. It seems the S_COVER SENSOR_TYPE uses V_DIMMER but I'm not sure how that was figured out.

@Damme said: 1;1;1;1;1;1\n sorry im from argentina and my english is very bad xD the problem is... i can send "255;255;3;0;4;2\n" from vb.net programm to arduino gateway in COM port and then the gateway send the same command to the sensor to change de ID vb.net --> arduino gw ---> sensor but i think the gw dont read the incoming data at now im use your script and work fine

@Damme The actuator/sensor class does not have any build in code for keeping track of latest value. You have to implement this yourself by answering incoming request messages.

@Zeph Yeah, I know, but I didn't want to devote a whole article on baudrate calculation!

Just in case it's useful to somebody, my current approach is: // Debug PRinting with LiNefeed and maybe Flash strings or 2nd mode param #ifdef DEBUG #define DPR(x) Serial.print(x) #define DPR2(x,m) Serial.print(x,m) #define DPRLIN() Serial.println() #define DPRLN(x) Serial.println(x) #define DPRLN2(x,m) Serial.println(x,m) // saving string in Flash ProgMem #define DPRF(x) Serial.print(F(x)) #define DPRLNF(x) Serial.println(F(x)) #else #define DPR(x) #define DPR2(x,m) #define DPRLIN() #define DPRLN(x) #define DPRLN2(x,m) #define DPRF(x) #define DPRLNF(x) #endif This allows substitute for println() with no args, and for print(val, HEX) type modes as well. I got tired of typing the extra F(...) so added macros to incorporate that too. You can make this into a library to include as a .h file - as a note, you still need a corresponding .c file even if empty.

@marceltrapman @hek that would mean sketched upgrade, but I plus it !