What is W3P? Is this some sort of CANBUS?

Some thoughts.

The last sleep study I had was simple - they sent me home with a recording device attached to two finger sensors; one was for heart rate and oxygenation, one was supposed to detect REM sleep (both had lights aimed at the skin or fingernail, did not appear to be accelerometers). I was surprised that they could detect REM sleep in that manner, but it would be worth looking into.

I wonder if one could detect movement with a cheaper BLE wristband, like the Xiomi MiBand? Not sure if anybody has cracked the OTA protocol. (OTA meaning generic Over the Air, not FOTA = Firmware/Flash Over the Air). I used to have one (before some firmware update from Xiomi bricked it), and it had a very long battery life and was small).

Building one's own wearable device - homebuilt and yet sturgy seems likely to be bigger and clunky; but maybe others can build tiny wearables.

Doppler Radar - I don't think my turning over in my sleep would result in a lot of motion towards/away the sensor from if mounted on the ceiling or high on the wall.

Antenna Effects (RCWL-0506) - might work if mounted close enough. Perhaps multiple devices. Worth considering. (These are NOT radar despite advertising, but do detect local movement).

One thing which might also work is a camera near the ceiling, attached to some image processing (NOT to a recorder!). Upside - it might be able to guess about movements of two people. In our case, we'd need to filter out cats who come and go all night (smaller areas?).

I recall reading a calculation which suggested that the LNA+PA version of the nrF24L01+ would not have a huge increase in range for a two-way connection with a regular transceiver; mainly because the receive side would not be much enhanced after SNR was taken into account (apparently the LNA was not that low noise, as the limiting factor for receiving). For one-way transmission from the PA unit or two way between two LNA+PA units, the improvement was much better . Was that post here?

Anyway, a higher gain antenna should help, as it increases signal strength and SNR in both directions. But is it true that higher gain is (almost??) always at the expense of a narrower emission pattern (kinda like using mirrors and lenses with a flashlight - the same power can be emitted weakly in all directions, or more strongly the smaller the focused beam)? And likewise for receive. For the example antenna in this thread, I believe the gain pattern is sort of toroidal - best at right angles to the antenna, less than unity along the axis. To get 9 db this would need to be a fairly flattened toroid (a stepped-on bagel). So in general, antenna gain is not an unambiguous "win", but rather involves a tradeoff which may or may not be worthwhile for a given system.

That can work well for a ranch style house which is mostly 2 dimensional, but for a multi story house the low transmit/receive gain along the antenna axis sometimes needs to be taken into account.

@tbowmo I agree with keeping things simple to implement, particularly on the Node & Gateway side. And it doesn't hurt that this would likely also keep things simpler to implement on the Controller side (ie: simpler plug-ins/adapters/drivers to write, which is a positive even when resources are not so tight.).

We might be able to nevertheless implement some kind of multi-value packet concept tho. I added a comment to the 3.0 doc about a simple and low overhead way to allow homogeneous arrays. That might or might not be worthwhile.

Robosensors's use case would involve some kind of tagged sub-unit approach, with multiple id/value pairs, yet another concept worth considering.

@tbowmo I made some related comments some while back when 2.0 was being developed, but then I disappeared from MySensors for many months (life does that). So I understand that it's too late for changes to that, and I am only planting seeds for the future, accepting that many will not sprout soon, or ever. The current spec is already a good effort.

The comments about more specific documentation can still be implemented, tho.

Perhaps I can help with comments on the binary protocol. The problem is that it has to map nearly 1:1 into the serial protocol, right? Or not?

I continue to be impressed with the quality of this community.

I've been gone for a while, but this seems like a nice next step. Feel free to move these comments to the forum if that make more sense. If it's too late for this round, perhaps they can be useful for the next revision.

0. I still think the controller (or if need be, the gateway) should do any neccessary conversion between metric and imperial units, rather than pushing it down to every node; it seems like some kind of violation of partitioning to push that UI customization concept (which in many controllers the user can toggle freely or even display both ways) down to the node level, where it adds unneeded complication. But I'll let that go.

1. It would be good to augment this with a systematic description of the underlying value type (int32, float32, string), and implied units if appropriate (potentially two units, for metric and imperial). For example, is wind speed in m/s or km/hr (assuming metric)? Is pressure in mmHg or hPA?

2. Aside from the type and implied units, there are a few hints given already - what 0 and 1 mean, an enumerated list of valid string values, color given a strings of hex digits, position as a multivalued structured string, etc. Keep those as notes in augmented docs as described in #1, and add more a needed (eg: IR commands)
   2A) Is there any logic to when enumerated values are encoded as integers, and when they are encoded as strings from a controlled vocabulary? Could we get by with one or the other, rather than this hybrid?

3. How do the semicolons internal to V_POSITION interact with the semicolons in the message field structure? If the same character is used for both, some note about that is needed. Or use commas in the former (substructured payloads) and semicolons in the former (overall message structure).

4. I'm glad to see that a distinction has been made between sensed light levels in Lux and uncalibrated light levels. Generalizing, I can see four types of possible reporting of such things. 1: uncalibrated results in arbitrary units (eg: ADC values of a LDR+resitor voltage divider), 2: scaled results 0-100%, 3: reporting in predefined units understood by both sides, like Lux, 4: reporting in uninterpreted units which can only be displayed but are not parsed. In the first case, I think the only thing to define for a given V_variable is whether brighter should be reported as higher or lower. This standard chooses 0-100% for V_LIGHT_LEVEL. Could't that be reported as V_PERCENTAGE instead? That is, use V_PERCENTAGE for any sensor reporting in scaled percentages.

5. If the protocol is going to allow for both uncalibrated and calibrated values (the latter in implied units), as with light levels, then I think it makes sense for the value with implied units to be the more specific variable; that is, V_LIGHT_LEVEL should be in lux, and V_LEVEL (or V_PERCENTAGE) would be used for the generic values, without units.

5A) V_LEVEL currently seems a little convoluted. It appears that the implied units depend upon which S_sensor the variable is associated with, which kind of breaks the pattern that units (if any) are implied by V_variable. And for S_DUST, S_AIR_QUALITY) there are no units. So for a calibrated light level in lux OR an uncalibrated dust level, use V_LEVEL but for an uncalibrated light level use V_LIGHT_LEVEL. V_LEVEL seems to be a grab bag of conceptually unrelated magnitude values, some with per-S_sensor implied units and some without. This could use rethinking. How about if V_LEVEL was used for any values which do not have implicit units (see #1 above), and V_PERCENTAGE was used if the value scales to 0..100%. Other V_variables could have pre-specified implicit units (metric and imperial).
5B) V_UNIT_PREFIX is really more of a suffix than a prefix. But this can work well with 5A above. If a value is reported as V_LEVEL then there are no interpreted or parsed units involved and the controller is not expected to be able to interpret or convert units. However, V_UNIT_SUFFIX could optionally supply a free text string with can be displayed after the value. So if you are reading a LDR and reporting the raw ADC value (or inverted value to ge the direction right), use only V_LEVEL. If you are reporting something in units not understood by the system, then use V_LEVEL and describe the units in V_UNIT_SUFFIX. (And if you are reporting percentage, use V_PERCENTAGE).

6. Semantically, there are two kinds of outputs: set-current-value which sets a new state to be retained, and trigger/command which performs some action once. It's kind of like edges and levels in hardware logic. Setting the same value twice is harmless, but issuing the same command twice may have different effects than sending it once. Most of the outputs are about set-current-value. However, some are commands - like sending an IR code.
   6A) What do V_UP, V_DOWN, and V_STOP mean? Unless they contain payloads to configure a (retained) movement speed or something, they seem more like commands/triggers rather than set-current-value. In that case, it makes more sense to have a V_SHADES variable which is set to 0,1,2 for stop, up and down (which are mutually exclusive), than to have three variables which could be set in parallel. Likewise with V_SCENE_ON and _OFF. These should be handled with one V_variable, much as sending a IR command. This is also easier to extend for an additional command to the same device - just define additional values to action associations, rather than needing to add a new V_variable.
   6B) (A shade controller which could set/report percentage opening could use V_PERCENTAGE)

7. Likewise there are two kinds of inputs: report-current-value and trigger-event. Mostly this protocol is about report-values. However the trigger functionality comes up in terms of V_TRIPPED, which is often implemented as a trigger. It should be made explicit what resets a triggered state: some systems use autoreset where after one report a device goes back to untriggered (trigger/event); other systems will keep reporting triggered forever until separately reset by some other means (report-current-state). We should be clear which mode this protocol expects.

It's good to see the ongoing refinement of MySensors and related initiatives! These are definitely meant to be helpful, not as criticism! Your work is much appreciated.

@gregl said:

isn't the key difference of the two that one 32u4 has a built in USB controller, whereas the 328p doesn't and relies on an external USB controller (FTDI usually.)

That's important, but there are many other differences vs ATMega328p. Offhand, there's an extra 0.5K RAM. Second 16 bit timer (Timer3) instead of 8 bit Timer2; plus high speed 10 bit Timer 4. SPI and TWI on different pin #'s (as seen by Arduino). More ADC pins, and a 10x/200x differential amplifier; different voltage ref (2.56v vs 1.1v). And various changes to interrupts or registers based on these. So some less-used libraries need porting, as well as changes to example code. Not sure how these differences affect the core of MySensors; you might have to try it out. There's a good chance that it would work, or that the changes needed would be minor.

The Leonardo is gone from the Arduino.cc product line, but the Micro is still sold so presumably the chip continues to be supported.

I was thinking to migrate to the Raspberry Pi (and try out various controller software).

However, I am hearing about problems with wear on SD cards; apparently the cards can fail after too many writes. There is no TRIM control as with SSD's, so there is limited ability to wear-level. So there are reports of periodic SD failures with 24/7 software running on a RPi. That would not be ideal for a home controller!

Has anybody had problems with this? Is some controller software better than others in this regard? (The problem can be reduced by using RAM disk (tmpfs) for highly volatile files).

@flopp said:

12v can be handle by the Arduino Pro min on RAW pin

Cars go well above 14V during operation (as well as having noise glitches on top of that). If the regulator is only good up to 12v, operation could be marginal. Hence the suggestion from @tbowmo of a couple of diodes in the power feed, to drop a bit of the voltage as seen by the regulator.

OK, let me see if I understand your overall flow.

You have your node connected to switched 12V power in the car. When you turn on the car, the uC gets power, when you turn off the car it loses power. When the car is cranking, the voltage drops enough that it tends to reset again (or else the cranking position on your key switch actually cuts off auxiliary power used by the uC).

So if you are at home and in range, loop() is called by the Arduino runtime just once; at the end of loop() the uC goes into an infinite busy loop rather than return, staying there until power is lost again. If you are away from home or the packets are lost for other reasons, resend() will cause a return from loop(), so that loop() will be called again by the Arduino runtime, so it will just keep trying until either power is lost, or it makes contact with your wireless network again.

Meanwhile every time it starts, the first byte of eeprom is incremented in setup(), and then loop() tries to fetch VAR1, and send VAR1+eeprom(0) back. If it succeeds, then the first byte of eeprom is zeroed.

Right?

That sounds reasonable. My immediate concern would be inconsistent operation during cranking, if the input voltage went just low enough to make the uC unstable. If your car's wiring cuts the power entirely, not a problem. Likewise there appears to be time for the uC to boot, and fully update eeprom, before losing power during cranking. (It's best not to be writing eeprom as voltage drops). It appears that those are not problems for your system tho.

@punter9 Thanks for the link, that gave some good background info, and some hope that those of us who are interested in playing with it will eventually be able to get one. (By pure chance, I happened to stumble across it minutes after it was first released, but didn't order one as I didn't have an immediate need, and I already have too many processors which I bought hoping to find a good use for already! Nevertheless I'll probably get one someday.)

I wasn't commenting on the quality of the hardware, just on the suitability for our purposes; parts which are only available in quantity one every few months IF YOU ARE LUCKY have some limitations.

From the article you linked, perhaps that will eventually change. We'll see. how soon. It's so cheap that if they don't keep limiting the quantities, one customer could buy up the full month's supply for embedding in a commercial product.

I'm wondering how it would be useful to us in DIY home automation tho.

As a node, I'm not seeing it as a major contender. Let's compare it to an Arduino Pro Mini (under $2 shipped). The minimal RPi zero plus memory, shipping and tax is going to be several times that.

The RPi Zero as node takes a lot more power to run and will not power up and down so quickly and gracefully, so it's not going to work well with battery power (and will have a larger passive load on mains power). It tends to require a whole OS which often gets in the way of direct interfacing with hardware, and requires system administering. There aren't as many sensor libraries for it. It has a much faster CPU and far more memory, but for most nodes that's just overkill. I'm not seeing that it would be competitive for most nodes even at the same price as an APM. But there must be some special purpose home automation nodes where it would be useful - any ideas?

Of course, it would work as server for some Home Automation Controller software. But you only need one of those, and how much money would it save once fitted out (relative to total system price) compared to using a RPi 3 (with built in WiFi and BLE) or RPi B+ @ $25, or BeagleBone Green?

So I'm still wondering what niche it would fill, within our domain...

What ideas do people have for making good use of a RPi Zero as a MySensors node, if it was easily available at the nominal price?

(Understand, I'll probably eventually get one to play around with because it IS cool, but not necessarily for HA. I also have a $9 C.H.I.P. on order, and a $19 PINE A64, and a RedBear Duo, etc. But those are to feed my addiction, I don't see them as changing the DIY Home Automation landscape).

If I understand, sometimes when you think you should be seeing 100%, the light is actually off?

You are counting on the triac to latch and hold until the next Zero Crossing. However a triac needs a certain level of current in order to latch. If you try to trigger it too early in the AC cycle (while the AC voltage is still close to zero, just starting to rise), the load may not provide enough current to latch the triac. This is especially true with some kinds of loads. For example, LED Xmas lisghts don't conduct until the AC instantaneous voltage rises above the combined Vfwd of 25-50 series LEDs.

One way to test this hypothesis is to lengthen the pulse. Or you could adjust your timing multiplier.

About 50% faster, uses about 50% more power, same memory.

Has built in WiFi and Bluetooth 4.1 (with BLE)! Uses tiny chip antenna on board, so who knows about the range. (There is an unpopulated SMA footprint, but no certification).

Most everything else is the same, for good compatibility.

Same price as the RPi 2 (which continues to be sold).

It's hard to take the Raspberry Pi Zero seriously. It's now over three months since it first went on sale, and it's rarely in stock anywhere for more than hours; when you can find it, you usually have to buy it with some kind of overpriced "kit" for $30-60, with a limit of one. If you did get one and you were to fry it, or want to build a second device using it, it may take you months to find another one. They've sold over 3 million Raspberry Pi 2's, so they know how to ramp up production if the want to. All this makes the RPi Zero seem more of a gimmick for "bragging rights" to a nominal $5 computer, than a serious option for our purposes, unfortunately.

@GertSanders said:

It seems you have removed the crystal and capacitors and plan to use the internal oscillator, I did this as well. Works most of the time, but uploading of sketches can give transmission errors of you go above 57K6 baud. Better to transmit at 36Kbit then (needs a change in the BOARDS.TXT file of Arduino IDE)

76K8 baud works better than 57K6 (division from 8 MHz has less error), and there are Optiboot variants which support it (with theBOARDS.TXT change you mention). Or 38K4 baud (half that) as you suggest, which is no more timing accurate than 76K8 but by being slower still may give more margin for sloppy edges or the like - if needed.

I am guessing that the babies could be repurposed as single unit mysensor nodes (integrated Atmega328 + nrf24L01+ on one small PCB). More expensive than an Ardu Pro Mini + nRF, and fewer I/O's, but perhaps useful for it's small form factor.

@cranky said:

Or that if the internet goes down, all my devices go dumb? Somehow

Or if the company sponsoring the proprietary cloud component goes dark or changes their terms of service.

No, you are not alone. There is a place for cloud based services in home automation, but for many of us, being in the middle of essential communications is not it.

@petoulachi said:

BTW, what is the F() function ? instead of Serial.print("Sensebender Micro FW "); why using Serial.print(F("Sensebender Micro FW ")); ?

It's a way to save some RAM. A simple string constant like "Hello" takes up 6 bytes of RAM and also 6 bytes of Flash (program) memory (6 bytes includes a single "hidden" byte of binary zero as an end-of-text marker). At startup and before your code executes, that bit of program memory is copied to RAM. The F() thing is a "macro" which causes the compiler save only the 6 bytes of Flash (no Ram used). The print function can (through C++ typing) fetch those 6 bytes from Flash at runtime for printing. If you have long or many text constants in your program, this can add up to some useful savings,when you only have 2K of RAM.

See the "F() Macro" on this page: https://www.arduino.cc/en/Reference/PROGMEM

So you find very close to 5V at the pixel chip level while running?

You are probably not missing something basic, but instead have a tricky marginal situation that's genuinely hard to debug.

If it was low power from the 5v charger (just not enough milliamps available), you should still be able to control, say, one red pixel on at a time, even if "all pixels white" overloaded the power supply.

The level shifting is one thing to check as others have indicated. Some 5v chargers run a little high (charge the battery faster?) which might make 3.3v logic driving data input of 5V pixel more marginal. You could insert a logic level shifter, or use a loose WS281x pixel running at the 3.3v between your Arduino and the first real pixel (adjust your code to send out one dummy black pixel before everything else).

Alternately, you could insert a resistor in the data line. in case it has to do with transmission line effects. Say, 47 ohms - give or take.

Also some of the cheap phone chargers have a very noisy power output. You might try using multiple bypass capacitors of differing values (eg: smaller ceramic for high frequency, higher value electrolytic for low, etc).

This is one of those times that a 'scope could be handy - maybe even one of the very cheap ones, used carefully. I'd really like to see a trace of that power line.

I'm noticing more and more often project descriptions (including here) are omitting schematics, in favor of pseudo-photo wiring diagrams.

I find good old eletronic schematics a lot easier to read and understand. At a glance I can see "Ah, they are using D10 for the interrupt, not D9, so I would have to change the code..." or whatever.

I would really love to see projects always include a schematic; if it's aimed at beginners who may not find that sufficient, I could see sometimes supplementing that with a wiring diagram too. Even for them, having a schematic too may be helpful - either to answer a question, or to help them become familiar and comfortable with schematics if they want.

Am I just an old fogey, or are there others who prefer schematics to wiring diagrams?

Soapbox off.