What is W3P? Is this some sort of CANBUS?
Posts made by Zeph
RE: Concept of a flexible but simple smart network
RE: Has anyone here made a sleep tracker for measuring your quality of sleep at night?
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?).
RE: Nrf24l01 with router antenna
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.
RE: 💬 Serial Protocol - 2.x
@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.
RE: 💬 Serial Protocol - 2.x
@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.
RE: 💬 Serial Protocol - 2.x
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.
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.
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?
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?
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).
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.
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).
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)
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.
RE: ATMega32u4 + RFM69 + MySensors = Working!?
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.
Raspberry Pi SD Card wear out?
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).
RE: Count car-starts
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.
RE: Count car-starts
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.
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.