Posts made by alphaHotel

@Larson said in Bootloading a barebones arduino:

I'm now talking to the chip in CMD terminal.

Well done! Let us know how it goes from here.

AH

@NeverDie Jonathan Oxer a little while back went through a similar process with programming headers for ESP8266/ESP32 boards. He discusses some of the challenges and tradeoffs in his video(s).

My personal opinion on trying to shrink them down is to keep with pin headers and just make them smaller. It's easy enough to find 1.27mm pitch IDC connectors. Your JST connector idea is good too. In the end, this is mostly a target audience scenario, it seems to me. My most recent board (still working on it), employed Oxer's ESPFlash header but I kept it with a 2.54mm pitch package because I have a ~million headers with that spacing and I wasn't cramped for space. (pic below)

If it's board-to-board as in connecting a radio module to an MCU backplane, then it's more of a use-case and dealer's choice scenario, in my mind. Those Molex SlimStack connectors look interesting.

I don't know if that helps or if I'm blowing smoke in the wrong direction. Just adding my voice.

@NeverDie said in Most reliable "best" radio:

I suppose it's more or less a conventional custom-built bed-of-nails.

@Larson said in Bootloading a barebones arduino:

Manufactures probably have to make assumptions on this and the prevailing one would probably be for a 16 Mhz crystal.

If it's straight from the factory, the fuses will be set to use the internal oscillator and there will be no bootloader.

Looking at your pictures, the chip is well aligned and in the correct orientation. If you're confident in your connections and the USBasp is working well with the Nano but not this chip, then I suspect that the chip was destroyed while being soldered. The fuses-set-for-external-clock possibility is very unlikely and probably not worth the effort to try to test/debug/rectify.

[Side note @NeverDie: I see that you used D20 and D21 to control the LEDs on board. You might want to make a note on the OpenHardware.io page that users will need to utilize either direct Port B manipulation or MCUDude's MiniCore to control those and no crystal can be added to this board (unless you hack the LED and resistor pads to do it).]

@Larson, as you have a few more of those chips, I'd suggest putting this one aside for now and trying again (I'm assuming you have at least 2 other copies of V001 boards as OSHpark tends to sell them in 3-packs). If you want to hold off for a bit to wait for that cool clamshell thing, you might also want to consider ordering the V003 boards while you wait so as to avoid the problem with the traces under the battery holders.

AH

Well done, forging ahead, @Larson. I wouldn't jump straight to trying to program a bootloader just yet though, we need to finish confirming communication with the chip and then if/when we get that going, look at how the fuses are set.

Looking at your post here, I believe you got these 328p's from Aliexpress (or similar). Did the listing indicate whether there was a bootloader or not? Bare chips, should be factory set to operate on the internal 8MHz oscillator, so that shouldn't be the problem. How many did you buy?

Based on your results above, at this point, it would seem that one of the following conditions exists:

1. There are solder bridges (shorts) somewhere - need to test with a MM in continuity mode, each pin with all other pins. Some should be connected (GNDs for example), but most should not.
2. The connections from your USBasp to the chip are incorrect. Again, you should be able to check this with a multimeter in continuity mode.
3. The chip is dead. (Long live the chip.)
4. The fuses are set to require an external crystal that doesn't exist. I just tested this by setting the fuses on my minimal 328P setup (see picture below). The result of which is that I now get the same error that you are getting. This is not likely the case for you but it is a possibility.

Here's a pic I just did checking continuity between the MISO contact on the USBasp and the corresponding chip pin on a minimal setup 328P for reference. Disregard that my multimeter is indicating no continuity, (my son took the picture at a bad time as I was making/breaking contact), you'll get the point of the shot though.

Also, take a close-up picture of the board/chip and post it here for us to see what you've got going on.

Carry on.

AH

EDIT: to add the 4th possible condition.

Hi @GertSanders,

Do you happen to still have the Eagle project files from version 3 you created and shared on OSH Park? I'd like to add a set of pads for the mini smd version of the NRF24L01. If not, I'll just use the version 2 files from openhardware.io and try my best to recreate the changes you made between them.

Kind regards,
AH

@NeverDie Awesome. thanks.

@NeverDie In considering a version 3, please consider turning the via in the following picture into a through-hole. it would allow for easier connection of a reset pin if needed to program the 328p with a programmer.

@Larson said in Most reliable "best" radio:

I don't think I can reach the fuses if the 'target' chip doesn't have a bootloader. Do I have that wrong?

You can reach (read/write) the fuses with a USBASP regardless of whether there is a bootloader. If you have any troubles, shoot me a message in the chat or start a new thread somewhere and I'll help you through it.

@NeverDie said in Version 2.0 atmega328p test platform:

They're onlly there in case you don't have any interest in measuring current and, thus, don't care to install the 4 header pins or the header pin jumpers.

Thank you for providing this insight. I enjoy learning by trying to understand someone else's perspective. It's not always provided as clearly or freely as you have (and do). Very much appreciated.

@alphaHotel said in Version 2.0 atmega328p test platform:

had to scale it 0.4 in X, Y, and Z dimensions

Update: That's only with the WRL (VRML) files as that file format is "dimensionless" it seems. I'm just learning FreeCAD for manipulating these 3D models so this is my learning curve. The preferred 3D model for CAD programs is STEP and with those, I didn't have to scale or more precisely the scaling factor is the default 1.0. I may remove the WRL files from the repo.

@NeverDie I wanted to have a closer look at your rev 2 but didn't see a RAR archive of the Kicad project. Don't upload it now though, I can wait for rev 3 for that. In looking at the schematic though, a question came to mind. What's the purpose of the 2 zero ohm bridging resistors, R6 & R7 in the schematic? Could you use a solder jumper/bridge there instead for the same purpose?

@NeverDie said in Version 2.0 atmega328p test platform:

Yes, please! Sounds like it may be very useful!

Here's the repo. I only just now created the footprint for the 2-clip version so check measurements and such. Also, when I attach the 3D model to the footprint, I had to change the orientation 180 degrees and offset it by the thickness of the board and had to scale it 0.4 in X, Y, and Z dimensions. Hope it helps.

@NeverDie I hit up Keystone Electronics for a 3D model of the battery clip (p/n 92) and then did a little work on setting up 3D models of 2 and 4 of them together - though the 4-piece model is based on the spacing of 16.8mm between centres. If you're interested, I'll share them in a Github repository, since I can't upload them here.

@Larson said in Most reliable "best" radio:

My problem today is bootloading the brand new 328's with my old USBASP. The IDE says something about “cannot set SCK period” and then “initialization failed”.

If you have a second USBASP or an Arduino of some sore lying around, you could try to update the firmware on the USBASP. I recommend this edition, latest release and a Google search for "how to update usbasp firmware". You may see that with release v1.06 of that repository, there was an improvement that "Includes automatic SCK slowing".

Of course, the problem may be more rudimentary. Can you read the fuses? Are they set to use an external oscillator that doesn't exist?

@NeverDie I thought your turnaround time was decent compared to mine. It has been taking up to 3 weeks for me to get mine from OSHpark. The last fab I ordered, I priced it out at PCBway but they were $29 versus OSHpark's $16. I do find though that within days of sending it off for fabrication, I'm making improvements to the design and kicking myself for placing the order too soon.

@NeverDie, Thank you.

@NeverDie said in Most reliable "best" radio:

I widened the separation between the batteries, and now the clips aren't at risk of shorting against one another.

It's looking good! I'm curious, how far apart are the battery clips now (center-center)? I noted on the original board layout it was 15.62mm. I'm guessing it's about an extra 3mm based on the lines of the silkscreen and the size of the mounting holes you added.

Also, an off-topic question for you - I believe I read in a thread somewhere recently (not sure which one though) that when adding a USB port you prefer USB Mini. Which footprint do you like to use and where do you source them from?

@NeverDie said in Most reliable "best" radio:

@alphaHotel Reporting back: I received them, and mine did not come with any antennas.

That's as I expected too because of the lack of any photos in the listings. Thanks for confirming, it's good to know. I do have a handful lying around from old WiFi routers as you mentioned.

@Larson said in Most reliable "best" radio:

Yes, I think I got your version from Github. I will learn how to send a pull request. Cool, so this is how collaboration works? I'm new to this.

Please don't add to your personal learning curve to create a pull request. It's not that important, at all.

@Larson said in Most reliable "best" radio:

I shrank the frame of the board to minimize the interference with the TestPlatform neighboring pins

Nice! How wide is that VCC trace/plane at its narrowest point now?

If you got it from Github, are you able to send me a pull request?

@NeverDie said in Most reliable "best" radio:

Adafruit's Clue device uses the KLJ-5030, which is 5mmx5mmx3mm:
At higher cost I notice that there also exists a KLJ-4020, which is 4mmx4mmx2mm

Yikes! Watch out for those shipping costs. Check my math, 4mm x 4mm x 2mm x 20 pcs = 640 cubic mm = 0.640 cubic cm = 0.0391 cubic inches, from China for $72 shipping? They must weigh a ton (or a tonne). LOL!

Seriously though, good find! I think I'll keep shopping around for a better price though.

More for my own future reference than anything else, the distance between the two AA battery clip mounting points is 15.62mm centre-centre.

@Larson said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

On your recommendation I'm looking for this solder as well. For those who follow this thread I found it here.
The solder diameter that came with my Chipquick SMD1 Removal kit was enough for one job, maybe. The linked 4 Oz. supply will last some time for me.

That's not quite the same stuff. What I use has a small amount of silver content in the alloy. You can find it here at Mouser.com. The smallest size they have though is the 8oz which is basically, a lifetime supply for me at least.

UPDATE:

• I've created a Github repo for my version of the nRF24L01 adapter board.
• I've created an OpenHardware.io project for it referencing the Github repo to extract/generate the files.
• My OpenHardware.io project is being reviewed before it is published. When its available you'll find it at https://www.openhardware.io/view/32973/nRF24L01-Adapter-Board-AH.

I've done it this way partly as a test as it ties back to this thread about sharing a complete set of KiCad design files. I'd appreciate any feedback on being able to open and edit the files. Also, feel free to submit a pull request as a test of collaborating with Github and KiCad but only if you're interested in the results too.

Edit: OpenHardware.io project is now available publicly.

@NeverDie said in Most reliable "best" radio:

OK, I updated the project archive to include nRF24L01 symbol and footprint libraries which include those symbols and footprints

Awesome! Thank you.

@NeverDie said in Most reliable "best" radio:

@alphaHotel said in Most reliable "best" radio:

@NeverDie With the first version of the battery/MCU board, you lamented running traces directly under the batteries. You have the space now to re-route them but choose not to. Did you find a way to resolve the issue it caused?

Actually, I fixed it on the new version (pictured above). The red traces run on top, so they're adequately isolated from the battery holder metal, which is on the back side except for the through-holes where it sticks through the board. Where I ran into trouble was running traces on the back side, beneath the battery holder metal. If the battery holder metal was pressed up hard against the board, some shorts resulted on some of the boards. The workaround was to not press the battery holder metal hard up against the board, but the new version removes that concern entirely.

Okay, I see now. I misunderstood the original issue and also didn't think about the top/bottom side orientation in relation to those traces vis-a-vis the battery holders. Thanks for clarifying.

@NeverDie With the first version of the battery/MCU board, you lamented running traces directly under the batteries. You have the space now to re-route them but choose not to. Did you find a way to resolve the issue it caused?

@NeverDie said in Most reliable "best" radio:

Done. Posted the .rar file to the project files. Let me know if you have any difficulty with it.

Thank you. I didn't have any issues with the files though it did warn that the footprints for the radio modules are in MyGlobalLibrary, which I don't have. See the screenshot below. If they could be put into a library within the project, it would be more portable than it already is but I was able to work with it as is.

I made a few mods including adding a ground plane and I'll try to get a repo on GitHub up and running for it tonight after work. With a new version in the works, perhaps I'll hold off getting some of these boards fabricated. In the interim, here's a view of my 3D model.

P.S. In case you're wondering, the possible next version has not only pluggable radios (as the original version had), but also pluggable MCU's, to make it easier to try different MCU's. I'm not sure yet whether or not it's a good idea, but since it's not rocket surgery I figure it is just easier to try the idea out than to overthink it.

At one point in this thread, I marvelled at the battery shield and wondered about having it separated from the MCU. Just conditioned power on the first shield then MCU, then radio. The complexity of it though is beyond my current level as I don't have as much experience with alternative MCU's (though I've been thinking we need to start looking at something with more program memory, like the ATmega4808/9). On the other hand, it should be just a matter of defining what needs to be passed from shield to shield (layer to layer?). Power, ground, SPI signals, perhaps I2C signals and a few other GPIO signals. Please do though consider lining up the pins such that they would also fit a breadboard layout.

@NeverDie

I think what he's saying there is that since the FHSS E34 has a built-in mcu and is operated using AT commands over UART, the comparable UART E32 module uses the same AT commands--which is about the only way I can imagine an E34 could be drop-in compatible as a replacement for the E32. These particular types of modules are advertised and sold as "wireless UARTs", and so the underlying technology is more or less transparent to that kind of solution.

Thanks for that explanation. It makes more sense now.

Yup, already got a 10uF cap on it on the adapter board posted to openhardware.io: https://www.openhardware.io/view/22656/nRF24L01-adapter-board

I saw that picture after I posted and smacked my head, of course, you did. On a related note, would it be possible to get the Kicad files for the nRF24L01 adapter board? I'd like to take a stab at building a couple of these but I want to put most of the face-down silkscreen on the face-up side too.

@skywatch said in Most reliable "best" radio:

@skywatch said in Most reliable "best" radio:
Thanks. What was it you were wanting me to notice about the e32 library? If it was about the FHSS, that was an e34 module in the youtube video.

Oh darn it! - I got it mixed up - I am sorry for posting the wrong lib!

At about 3:12 in the video, he references the Lora E32 and says the pinout is the same and that "the software is compatible". I don't know if he means the library, the code (the module does the frequency hopping) or the Ebyte software for configuring the modules but it would be good to know more about it.

@Larson said in Most reliable "best" radio:

To extract the *.rar in Windows 10, I downloaded a utility program (WinZip 21-day trial).

7-Zip is an open-source alternative that will do the job equally as well. https://www.7-zip.org/

@NeverDie said in Most reliable "best" radio:

It does already have 100n (=0.1uF) across the DC power line, extremely near the inputs to the nRF24L01

Add a 10uF cap there. I found these radios are more stable with enough power to draw on during transmission.

@NeverDie said in Most reliable "best" radio:

As a result, I just now ordered some of these E01-2G4M27D

Please let us know if they arrive with or without antennas. I've been eyeing them recently but haven't pulled the trigger yet.

@NeverDie said in Most reliable "best" radio:

I've looked for tiny piezo's that could maybe do this, but they all seem to be different degrees of large. I know it should be possible to be tiny, becaue, for example, a digital wristwatch is able to make audible beeps. On the other hand, after looking at some teardowns, I guess digital watches uses piezo disks that are at least 1/2" in diameter. Hmmmm.... Is that really as small as it gets? Anyone here know? What about hearing aids? Surely they have something smaller. The smallest thing I've found so far has been this: https://owolff.com/page140.aspx?recordid140=534&output=pdf&delay=3000&margin=1cm which is 5mm in diameter. So, I guess forget mounting anything directly to the PCB board: wired discs are the way it's done apparently and then just tuck it somewhere inside the project enclosure.

I found these recently: https://www.cuidevices.com/micro-buzzers. Digikey seems to carry them but the smallest was listed as "0 quantity in stock" (https://www.digikey.ca/en/product-highlight/c/cui/micro-buzzers). The 4mm square version was available but of course that's just my local digikey, YMMV.

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

@Larson said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

0.4mm diameter Kester Rosin solder.

I'll put it on my list. After the Male/Female antennae discussion above, I'm sure I got my order wrong - so I'll have a new running list shortly when everything arrives. I checked my solder with a caliper since the dimensions are listed in Chinese: it is 0.6 mm so I'm not far away. I do like the feel the smaller diameter has in comparison to my larger solder so I'm sure 0.4 mm will even be better.

Yeah, I was using 0.635mm MG Chemicals solder previously, but I found I had to drown the radio modules in rosin flux afterward to eliminate solder bridges, etc. Perhaps part of the difference may be that Kester uses a different formulation for its in-line flux than MG Chemicals? I suppose that could also have something to do with it. So, maybe it's not entirely diameter, but having now worked with the two different diameters, my gut intuition is that the smaller diameter is helping.

Anyone else reading this having any opinions on the matter that they are willing to share?

I swear by the stuff in the picture below. It melts at a lower temperature(179 C) so, as an amateur, I feel safer keeping my iron at a lower temp and in place a little longer when I am working with IC's. I like that it's thin too as it is easier to control how much you apply. I have no issues with it, it flows well and doesn't create bridges (unless I use too much).

@NeverDie said in Anyone using/tried the E28-2G4M27S 2.4Ghz LoRa SX1280 27dB module?:

As you can see, I wouldn't want the batteries to be any closer together than they already are, or they would likely short out between them. As it stands, they're firmly in place, so no worries for now. These kinds of placement tolerance issues are hard to vet in advance prior to building a prototype. The keystone datasheet gave no guidance at all on side by side positioning. If I were to do it over, I think I'd give it another millimeter or two of safety factor separation.

Add some Kapton tape to the sides of the terminals next to each other to insulate against accidents without making it more cramped.

I've taken it upon myself to isolate the Si7021 Library found within the MySenesorsArduinoExamples repository and create a modern-style repository specific to the pared-down version from the examples and its use with MySensors sketches. The repository I created is ready to be submitted for inclusion in the Arduino Library Registry which would allow for easy download, installation and use by any user including from within the Arduino IDE or PlatformIO.

@hek @Yveaux @marceloaqno
The purpose of my post here is to ask permission to transfer ownership of the repository to the MySensors Organization on Github. as I feel that is where it should live. After that, I can create the pull request(s) needed to finalize the submission of the library to the Arduino Library Registry.

You can find my repo on Github.

I just saw on the openhardware.io site that you can import GitHub projects. That would be a great way to do it. Work locally, push changes to Github, and publish to openhardware.io when it's ready.

I've only just started playing with KiCad 6.0 myself. I'm liking it too. I picked it up in order to have a closer look at @m26872 's contribution of KiCad design files from 2015 (using KiCad 4.0 RC2!) for their Slim 2xAA Battery Node.

They seemingly created the zip file by simply creating a Zip file of the folders that contain the project. That may be the best approach.

I've been able to open it and although had some challenges remapping the libraries, as they were changed significantly between 4.0 and 5.0, I've been able to have a good look and have plans to change the orientation of the ICSP header to the edge of the board, if I can learn enough to do that.

As a test of that theory and as a contribution back to the community and @m26872 I tried to upload my copy of the design files in KiCad v 6.0 format but ZIP files are not allowed anymore.

@jkandasa Thanks!

Does anyone have a copy of MYSController they can share? The link to a dropbox folder says the folder is no longer available.

I'm trying to test out a new gateway device and it would make it a lot simpler to use MYSController that to start integrating it into my infrastructure.

@Anticimex I had to turn off MY_DEBUG to add the encryption directives. I also moved everything back to version 2.3.1 as I was still seeing some weird stuff going on like msg-type 169 (unknown) and attempts to route through nodes that don't exist. These things I guess may have been due to high ram usage. I think I was at about 78% w version 2.3.2 and basic encryption enabled but now...

Sketch uses 21542 bytes (70%) of program storage space. Maximum is 30720 bytes.
Global variables use 1108 bytes (54%) of dynamic memory, leaving 940 bytes for local variables. Maximum is 2048 bytes.

@Yveaux - I don't expect that it would have been high ram usage causing my initial issues as I wasn't using any encryption or signing before. I started seeing these problems when I moved to 2.3.2 but as I had also been dealing with a new sensor on my first Sensebender Micro, I wasn't sure what might be causing the problems. What do you think might have caused the received data type to flip from a float to an unsigned integer?

@Anticimex I've got it set to measure once per minute at the moment and force transmissions that have no changes every 30 but that's my testing stance. In the end, it'll likely be more of a 5 or 10-minute measurement and forced hourly.

@Anticimex Thanks. I've done some preliminary research into signing and encryption and have struggled a bit with taking it from concept to implementation. I guess I should roll up my sleeves and dig into the how-tos. This is intended to be a battery-powered sensor so perhaps I'll start with encryption first.

@Yveaux I'm using Nrf24's.

I've recently been updating my nodes and gateways to use the latest version of MySensors. I've also recently acquired a handful of Sensebender Micros and set one up in the pool shed to test/play and get some outside temperature and humidity readings. A problem I found though is that I was getting some anomalous data readings which completely throws off my time period data - see the 24-hour chart below.

Solar flares perhaps? I ruled that out.

I set up a test last night before turning in for the night and ran it for about 18 hours. I've collected and compared the debug logs of my node with those of the Ethernet and MQTT gateways that I have and found that the node is sending a valid float value at all times but the gateways will sometimes receive something different.

Node Debug Data (stripped to just the sending of one of the sensors)

4935 TSF:MSG:SEND,4-4-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:21.6
5480 TSF:MSG:SEND,4-4-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:21.2
6891 TSF:MSG:SEND,4-4-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:20.7
8331 TSF:MSG:SEND,4-4-0-0,s=1,c=1,t=0,pt=7,l=5,sg=0,ft=0,st=OK:20.4

And corresponding receives from the Ethernet Gateway debug log

Jun 04 00:55:20 DEBUG TSF:MSG:READ,4-4-0,s=1,c=1,t=0,pt=7,l=5,sg=0:21.6
Jun 04 01:02:35 DEBUG TSF:MSG:READ,4-4-0,s=1,c=1,t=0,pt=5,l=5,sg=0:1101633946
Jun 04 01:37:38 DEBUG TSF:MSG:READ,4-4-0,s=1,c=1,t=0,pt=7,l=5,sg=0:20.7
Jun 04 02:13:52 DEBUG TSF:MSG:READ,4-4-0,s=1,c=1,t=0,pt=7,l=5,sg=0:20.4

You can see that the data received changed payload type from P_FLOAT32 (pt=7) to P_ULONG32 (pt=5) !!!

Note that the graph above is from data collected by way of the MQTT gateway and as such doesn't specifically correspond to the debug logs above but I do see exactly the same flip of payload type in the MQTT GW log - though at different times from those in the Ethernet GW log

Now I understand that this is going to come down to noise in the radio transmission but it raises some bigger-picture questions for me.

1. How can I ensure that the data received by the gateway is specifically what the node sent?
2. Would using ACK and having the node confirm if what was sent was received correctly be a valid approach?
3. Would implementing message signing help in any way?

I'm at a loss on how best to ensure the integrity of the data being sent and collected. What are your thoughts?

Allen

What I had noticed and was trying to point out was that the error was:

[WARNING] Unknown option detected: --my-mqtt-user=pi, ignored

not:

[WARNING] Unknown option detected: --my-mqtt-user, ignored

@meach Configure is not seeing the = in your command line properly - so I'm assuming a cut+paste issue with character strings.

Ie. It's seeing the configuration option --my-mqtt-user=pi instead of --my-mqtt-user and a value of pi.

Try to retype that part of the command line manually and try it again.

A

EDIT: As an aside, I usually put my configure command line into a script and then just run the script. Handy when you come back to it 6-8 months later and wonder what configure options you used the last time you ran it.

@trs-80 said in OpenHAB 2.4 MySensors Serial Gateway - How to install:

Currently, it seems there is some bug going on with their build system or something. I actually had lodged an issue of my own (and even had submitted a PR to correct the documentation) before someone replied, pointing me to the root issue. So for the time being, instead of using https://dl.bintray.com/openhab/apt-repo2 location, you should use https://openhab.jfrog.io/openhab/openhab-linuxpkg repository location.

I ran into the same thing. Specifically, to get around this, the second instruction under the OpenHAB portion of the original post can be substituted with this:

echo 'deb https://openhab.jfrog.io/openhab/openhab-linuxpkg stable main' | sudo tee /etc/apt/sources.list.d/openhab2.list

EDIT: I've just noticed that they've updated the Package Repository Installation instructions to add the command above.

Further, if you care about issues such as software freedom (which I do a great deal) you might want to consider installing Azul/Zulu Java 8 (make sure it's 8!) which I have done, instead of Oracle Java. Azul's (also excellent) instructions can be found linked from the OpenHAB Linux install instructions. And that would also solve your missing repo problem, obviously.

If using Zulu Java, beware that the repos are not being maintained and are behind (see reference for manual instructions).

I used OpenJDK 8 for java with sudo apt install openjdk-8-jdk-headless.

I'm using an Ethernet gateway (on a separate Raspberry Pi) though which is a twist on all of this.

--Allen

@hek I was able to add support for stream message types to the log parser but can't perform a pull request against the gist. Here is my diff analysis if you're interested in this small update.

I also made a subsequent one line change to correct the issue that @BoresExpress noted a while back.

@mfalkvidd Thank you - MY_DEBUG_VERBOSE_OTA_UPDATE does look like it's exactly what I was looking for. Further looking into the code here though, it would seem that it gets defined automatically if we define MY_DEBUG.

Turn it around, when we define MY_DEBUG, we should see verbose FOTA (+ Core, Transport and Gateway) information in the serial log output.

I'll attempt some more testing tonight to see what I can see.

@mfalkvidd It was more a matter of me not mentally differentiating between OTA firmware updates and other potential OTA use cases when I searched for OTA related directives.

I don't feel I'm yet in a position to be able to make clarifications to documentation. I would like to be able to get to the point of putting together a handful of walk-throughs for beginners but I'm still in an experimenting and learning phase.

Time will tell.

-- Allen

Figured out that I misunderstood the purpose of this directive. I was thinking (had assumed) that it was showing more verbose information through the serial output for firmware OTA update traffic. Once I looked at the description for it, it was clear that it is intended more as an alternative to MY_DEBUG - as in don't send debug output to the serial but send it over-the-air instead. I was declaring both and they conflict.

EDIT: saying they conflict is inaccurate. The problem was in how I was using it (inappropriately).

-- Allen

@alphahotel

Here's the contents of mysgw.cpp.

/*
 * The MySensors Arduino library handles the wireless radio link and protocol
 * between your home built sensors/actuators and HA controller of choice.
 * The sensors forms a self healing radio network with optional repeaters. Each
 * repeater and gateway builds a routing tables in EEPROM which keeps track of the
 * network topology allowing messages to be routed to nodes.
 *
 * Created by Henrik Ekblad <henrik.ekblad@mysensors.org>
 * Copyright (C) 2013-2018 Sensnology AB
 * Full contributor list: https://github.com/mysensors/MySensors/graphs/contributors
 *
 * Documentation: http://www.mysensors.org
 * Support Forum: http://forum.mysensors.org
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * version 2 as published by the Free Software Foundation.
 */

#include <iostream>
#include <cstdio>
#include <unistd.h>

// For more options run ./configure --help

// Config file
//#define MY_LINUX_CONFIG_FILE "/etc/mysensors.conf"

// How many clients should be able to connect to this gateway (default 1)
#define MY_GATEWAY_MAX_CLIENTS 10

// Serial config
// Enable this if you are using an Arduino connected to the USB
//#define MY_LINUX_SERIAL_PORT "/dev/ttyUSB0"
// Enable this if you need to connect to a controller running on the same device
// You also need to define MY_LINUX_SERIAL_PORT above with the symlink name for the PTY device
//#define MY_LINUX_SERIAL_IS_PTY
// Grant access to the specified system group for the serial device
//#define MY_LINUX_SERIAL_GROUPNAME "tty"

// MQTT options
//#define MY_CONTROLLER_IP_ADDRESS 192, 168, 178, 68
//#define MY_PORT 1883
//#define MY_MQTT_CLIENT_ID "mysensors-1"
//#define MY_MQTT_PUBLISH_TOPIC_PREFIX "mygateway1-out"
//#define MY_MQTT_SUBSCRIBE_TOPIC_PREFIX "mygateway1-in"

// Enable these if your MQTT broker requires username/password
//#define MY_MQTT_USER "username"
//#define MY_MQTT_PASSWORD "password"

// Flash leds on rx/tx/err
//#define MY_DEFAULT_ERR_LED_PIN 12  // Error LED pin
//#define MY_DEFAULT_RX_LED_PIN  16  // Receive LED pin
//#define MY_DEFAULT_TX_LED_PIN  18  // Transmit LED pin
// Inverse the blinking feature
//#define MY_WITH_LEDS_BLINKING_INVERSE

// Enable software signing
//#define MY_SIGNING_SOFT
// Enable signing related debug
//#define MY_DEBUG_VERBOSE_SIGNING
// Enable this to request signatures
//#define MY_SIGNING_REQUEST_SIGNATURES
// Enable this to to weaken security for gradual deployment purpose
// (see signing documentation for details)
//#define MY_SIGNING_WEAK_SECURITY

// Enables RF24 encryption (all nodes and gateway must have this enabled, and all must be
// personalized with the same AES key)
//#define MY_RF24_ENABLE_ENCRYPTION

// Enable inclusion mode if your HA Controller supports it (e.g. Vera Controller)
//#define MY_INCLUSION_MODE_FEATURE
// Enable Inclusion mode button on gateway
//#define MY_INCLUSION_BUTTON_FEATURE
// Set inclusion mode duration (in seconds)
//#define MY_INCLUSION_MODE_DURATION 60
// Digital pin used for inclusion mode button
//#define MY_INCLUSION_MODE_BUTTON_PIN  3

#define MY_DEBUG_OTA
//#define MY_DEBUG_VERBOSE_GATEWAY
//#define MY_DEBUG_VERBOSE_RF24
//#define MY_DEBUG_VERBOSE_OTA_UPDATE

#include <MySensors.h>

#define ARDUINO 100
// This space is intended to be used to include arduino libraries

#undef ARDUINO

void setup()
{
	// Setup locally attached sensors
}

void presentation()
{
	// Present locally attached sensors here
}

void loop()
{
	// Send locally attached sensors data here
}

Hi folks. I've been working on building my sensor network for a couple of months now and although I've had some frustration, I've been able to work through most of the issues. I've recently started to work on getting OTA updates working and am finding it a challenge.

I wanted to try to get more debugging information specific to the OTA updates from both my test node and the gateway. In either case, when I add #define MY_DEBUG_OTA to the code in either my node sketch or my gateway's mysgw.cpp file and try to compile, I get compile errors.

pi@gateway:~/gateways/MySensors $ make
g++ -MT build/examples_linux/mysgw.o -MMD -MP -march=armv8-a+crc -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard -DMY_RADIO_RF24 -DMY_GATEWAY_LINUX -DMY_DEBUG -DLINUX_SPI_BCM -DLINUX_ARCH_RASPBERRYPI -DMY_PORT=8080 -DMY_RX_MESSAGE_BUFFER_FEATURE -DMY_RF24_IRQ_PIN=15  -Ofast -g -Wall -Wextra  -I. -I./core -I./drivers/Linux -I./drivers/BCM -c examples_linux/mysgw.cpp -o build/examples_linux/mysgw.o
In file included from ./MySensors.h:42:0,
                 from examples_linux/mysgw.cpp:87:
./core/MyGatewayTransportEthernet.cpp: In function ‘bool _readFromClient(uint8_t)’:
./MyConfig.h:2097:50: error: expected primary-expression before ‘)’ token
 #define DEBUG_OUTPUT(x,...)  OTALog((MY_DEBUG_OTA), true, x, ##__VA_ARGS__) //!< debug
                                                  ^
./core/MyGatewayTransport.h:82:30: note: in expansion of macro ‘DEBUG_OUTPUT’
 #define GATEWAY_DEBUG(x,...) DEBUG_OUTPUT(x, ##__VA_ARGS__) //!< debug output
                              ^~~~~~~~~~~~
./core/MyGatewayTransportEthernet.cpp:297:5: note: in expansion of macro ‘GATEWAY_DEBUG’
     GATEWAY_DEBUG(PSTR("GWT:RFC:C=%" PRIu8 ",MSG=%s\n"), i, inputString[i].string);
     ^~~~~~~~~~~~~
./MyConfig.h:2097:50: error: expected primary-expression before ‘)’ token
 #define DEBUG_OUTPUT(x,...)  OTALog((MY_DEBUG_OTA), true, x, ##__VA_ARGS__) //!< debug
                                                  ^
./core/MyGatewayTransport.h:82:30: note: in expansion of macro ‘DEBUG_OUTPUT’
 #define GATEWAY_DEBUG(x,...) DEBUG_OUTPUT(x, ##__VA_ARGS__) //!< debug output
                              ^~~~~~~~~~~~

...
It goes on like that for too many lines to post here.
...

Makefile:98: recipe for target 'build/examples_linux/mysgw.o' failed
make: *** [build/examples_linux/mysgw.o] Error 1

^^^ That's the output compiling the gateway.

This is a MySensors 2.3.1 ethernet gateway running on a Raspberry Pi . Same RPi has MyController 1.4.0_Final.

It compiles fine without that directive.

Any thoughts?

There's a broken link in the reference for MY_OTA_FIRMWARE_FEATURE in the Configuration section above (https://www.mysensors.org/download/sensor_api_20#configuration). I believe the correct URL should be https://www.mysensors.org/about/fota.