General Discussion

@dzairo no need to modify MyConfig.h. Just add the define to your sketch, if you want to override the default setting. Additional documentation: https://www.mysensors.org/apidocs/group__RFM69Newgrp.html#ga70bef975c2c3070e34c24770f7f301b9

@tmaster I think the phrase "that escalated quickly" comes to mind.. I can only speak personally in that I dismissed "Wifi" as a Node communication methodology due to limited structural penetration issues and the desire for complete separation between monitoring and reporting. Z-Wave operates in the 800-900MHz band so is less prone to structural blockage, externally it would take a dedicated geek parked in your back yard to break into that. My own issue with the blossoming of wifi incorporation in "a connected world" is that even your fridge can be used in a DoS attack, and it is pointless making comments about what CAN be done with a router, when the vast majority of consumers are only concerned they can check on their fridge 2,000m away without a ball's notion or concern who else may be affected. The comms protocol is less energy inefficient but it has a universal tag. I can see the advantage of "the cloud" but have a serious beef with dependency on that service, the other is living in a rural area where candles are common due to power cuts which also cut off the internet service externally. Yeah, burglar's paradise... except for the large dog and a Gatling Gun on heat sensors... Ok, one of them may be true ;) I almost went for Honeywell's Evohome system a few years back, local operations on 868MHz, well secured, but then came the spanner in the works, internet dependency. All my home kit is self contained 433MHz, and happy it works away 24/7, with no local geeks acquainted with http protocols interested in researching or interfering, happy... In short, the cheap options are cheap for a reason, one of which is insecurity for a price hence Zigbee etc.....

Can't remember if there where any specific books.. Probably some magazines like elector electronics in the 80's. There where a couple of danish magazines back in the 80's, that I read at the public library (I'm turning 46 in a couple of weeks).

Quite popular project after all.. https://www.kickstarter.com/projects/pokitmeter/pokit-pro/posts/2691302

@lammietv200 If the ship is made of metal then it'll be really luckly if it works. For watertightness and fire refulations you may not be able to drill new holes in any wall/bulkhead. The engine room most likely has a riser or other means of getting existing power and control cables in/out. So I would start looking there and thinking of a wired node as interference will be another concern in an engine room environment.

@mfalkvidd Not just the NFC chips, but their billowy antennas also add to their size. I wouldn't be surprised if a certain fully functioning nRF51 module has a smaller footprint: [image: s-l225.webp]

@alowhum most of these questions are way too advanced for me to answer, but I know that wait() calls _process() which processes messages and kicks the watchdog (through doYield()). See https://github.com/mysensors/MySensors/blob/development/core/MySensorsCore.cpp#L565 while (hwMillis() - enteringMS < waitingMS) { _process(); } By default, nrf24-based nodes do not use interrupts for message handling. There is nothing done in parallell.

Thank you so much, just the input I needed. Works like a charm, I have included the output from the serial port, if any one else wonders what to expect. __ __ ____ | \/ |_ _/ ___| ___ _ __ ___ ___ _ __ ___ | |\/| | | | \___ \ / _ \ `_ \/ __|/ _ \| `__/ __| | | | | |_| |___| | __/ | | \__ \ _ | | \__ \ |_| |_|\__, |____/ \___|_| |_|___/\___/|_| |___/ |___/ 2.3.1 16 MCO:BGN:INIT NODE,CP=RSNNA---,REL=255,VER=2.3.1 26 MCO:BGN:BFR before ShuntCtrl to clear EEPROM presss c now: 321 4156 TSM:INIT 4157 TSF:WUR:MS=1000 4159 TSM:INIT:TSP OK 4161 TSM:INIT:STATID=123 4163 TSF:SID:OK,ID=123 4165 TSM:FPAR 4184 TSF:MSG:SEND,123-123-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 5159 MCO:BGN:STP setup 5161 !TSF:SND:TNR 6164 !TSF:SND:TNR 6192 !TSM:FPAR:NO REPLY 6194 TSM:FPAR 6211 TSF:MSG:SEND,123-123-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: 7165 MCO:BGN:INIT OK,TSP=0 8288 !MCO:SND:NODE NOT REG 8372 !MCO:SND:NODE NOT REG 8455 !MCO:SND:NODE NOT REG 8539 !MCO:SND:NODE NOT REG [ %0PH 18.8 Vejr 18.7 ] [ %16PC 18.6 ->25 18.4 ] 8636 !TSM:FPAR:NO REPLY 8638 TSM:FPAR 8656 TSF:MSG:SEND,123-123-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: [ %0PH 18.8 Vejr 18.7 ] [ %16PC 18.6 ->25 18.4 ] 11094 !TSM:FPAR:NO REPLY 11096 TSM:FPAR 11114 TSF:MSG:SEND,123-123-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK: [ %0PH 18.8 Vejr 18.7 ] [ %16PC 18.6 ->25 18.4 ] 13550 !TSM:FPAR:FAIL 13552 TSM:FAIL:CNT=1 13554 TSM:FAIL:DIS 13556 TSF:TDI:TSL [ %0PH 18.8 Vejr 18.7 ] [ %16PC 18.6 ->25 18.4 ] [ %0PH 18.8 Vejr 18.7 ] [ %16PC 18.6 ->25 18.4 ] [ %0PH 18.8 Vejr 18.7 ] [ %16PC 18.6 ->25 18.4 ] [ %0PH 18.8 Vejr 18.7 ] [ %16PC 18.6 ->25 18.4 ] 23558 TSM:FAIL:RE-INIT 23560 TSM:INIT 23561 TSM:INIT:TSP OK 23563 TSM:INIT:STATID=123 23565 TSF:SID:OK,ID=123

@neverdie said in Sensor Up or Sensor Down: si7021 Didn't even think of that, but it makes sense.

@noclue said in Sensor advice: @hj_sk I want to control my idea. I have put my ideas out there before, only to be stolen. either do as Tbowmo suggests, or if you are afraid that we will all steal your idea, I can recommend to contact a electronic development company, that will sign a non-disclosure contract, a company could be this one (I'm not affiliated with the specific company) https://www.prevas.com/

@sebex this is purpose or the "ABC". They neeed to be exposed to outside air at regular interval (usually at least once a week) to recalibrate themselves and stay accurate for years.

Here is a review of this https://youtu.be/55tgEMTumGo Not sure why, it YouTube has started suggesting this kind of videos after I read this post

@neverdie said in Anyone here tried/using either Dragino LoRa gateway or some other LoRa TTN gateway?: Are you sure? I'm glad I asked, because from my reading I had thought that FOTA had been baked into the LoRaWAN specification for over a year now: https://lora-alliance.org/in-the-news/lora-alliancetm-enhances-lorawantm-protocol-new-specifications-support-firmware-updates I am sure, but I am unable to find a reference. Having it in the spec is not the same as having it implemented in the infrastructure. If you deploy your own TTN v3 stack (most of it is open source), you can probably get it to work. I've had on my todo to do this for a long time, but other things have priority. You can also but a commercial license for the commercial version: https://www.thethingsindustries.com/technology/pricing So far I have only seen one implementation of fota, and that's by arm, which has a hard requirement that your firmware needs to be built on arm mbed. https://github.com/ARMmbed/mbed-lorawan-update-client

@NeverDie I don't remember exctly, but voltage requirements for mcu only might be the same (approx). On modules, it can differ, depending on external spiflash&ram voltage requirements. I thought you were talking about the esp32-s2, announced a few months ago, which has usb and few more IOs for example but it's single core. the simple S version is maybe used as coprocessor, like on particle boards, if I'm not wrong

@bjacobse Thank you :)