@monte, I've implemented in PR https://github.com/mysensors/NodeManager/pull/517 something going in the direction you pointed out. Before explaining just a simple assumption first: NodeManager is intended to run on a number of different boards, most of them with limited memory so this capability has to take this constraint into consideration (hence no json parsing, reuse of existing communication mechanism, capability disabled by default, etc.) Apart from this, I found a sort of compromise to enable/disable sensors, even remotely and optionally persisting the status across a reboot. All the implementation details are within the PR (down below, the PR also include other enhancements) feel free to provide comments here or on Github. Hope it could be useful to avoid reimplementing the entire logic from scratch user2684 created this issue in mysensors/NodeManager open Core Multiple Fixes #517

Nice project manufacturers datasheets, RF appnotes etc all mention this, with results for different usecases (like gnd plane size etc). I mentioned it a few times on the forum: nothing under or near antenna (keep out zone) their matching circuit, and CE/FCC certif are based on their development boards+their antenna if external, often without enclosure. there are a very few pcb antennas which are resilient to untuning. ceramic or meandered pcb are usually more compact but less resilient (like when you approach your hand and device suddently has better or worst communication) once you change any of these parameters (board shape, gnd size, enclosure etc), it breaks FCC, and may need retuning, still you can get useable range. "ideally" tuning should be done once enclosed for example. manufacturers can't cover all cases. on my side, I try to follow these rules. and when interested in a design or a device, I check this. Mainly the routing+gnd, antenna choice, keepout zone, and orientation vs my usecase (long range needed or not for example)

So, while here I've decided to close my TODO list. The revision 1.4 is likely to be the last chapter in this design, and now it can be considered safe to order. It introduces some important final touches to the board, in particular: The orientation key (diameter 2.1mm) on the board edge. It's located between the Tag-Connect and the board main area, and initially can be used as an eyelet. After the Tag-Connect removal it works as an orientation key for the board. Full rework of the silk layer. Just to mention few: I hid all designators and decorated the board with eye catchy "52" over the nRF52 MCU, touched the antenna outline, and moved the git hash to the mainland. Review and cleanup the ground plane. The changes were tiny so it shouldn't detune the antenna, but aesthetics were definitely improved. You may also want to order the board in Afterdark colors now: Have fun!

Please Is it possible to buy only PCB? Do you plan also to release your sketch?

hello @berkseo can you share sketch for this sensor ? i am very intrested about this thank you PS: great job !

Can you tell something about the range of this node? And do you see a chance to post the schematic?

Could you please update the description with what component goes where on the pcb?

@nca78 I don't use ATAES132A. I put it in just in case I wanted to invest some more time using it. I now just use SimpleEncryption, it's secure enough for my purpose atm. (since the area I live in uses KAKU a lot, an insecure 433MHz lightswitch, I don't think anyone would be bothered to hack my temperature sensors. I found 163 433Mhz devices when I left domoticz logging for a couple of days.)

@scalz May I request you to share your code for it please. Thanks.

@scalz May I request you to share your code for it please. Thanks

I think you can just set the I2C pins in MyBoardNRF5.h without remapping the pins in MyBoardNRF5.cpp. Look in MyBoardNRF5.h, under the Wire Interfaces section. Set SDL and SCA to 30 and 31 as appropriate for your board.