Feature Request: Ahoy Arduino nano Port

[golfi200]

Hello Lumapu,

thanks for all your great work! I follow this project now for 2 month and learned a lot. My task was to bring the app to work on an Arduino-nano with Serial output. The main decoding shall be done by FHEM or python from external. So I skipped Wifi and MQTT. Finally its working, but I had to modify the ESP8266 code quite a lot.
Nevertheless I think I found some issues and solutions of the nrf24+ radio handling which would be useful for you as well:

• I structured the radio eval functionality of your app.cpp into methods of my new main.cpp (like copyPacket2Payload(), checkPayload() ...) to make the evaluation sequence clearer.
• the issue Feature Request: Von Zeit zur Zeit Missing Frames, Retransmit missing packets in order 0x81, 0x82, ... 0x8x #464 is solved in the way you have described (in case of no reception of REQ 15 then request again all at once again on next channel, instead of single polling)
• The function hmRadio.sendPacket() switches automatically to the next channel. That works fine for a single Inverter, but you lose track of another inverter and need to sync the channel again if you poll the next inverter. I thinks its better to store the last Tx channel per Inverter and give sendPacket() the Tx-chan as parameter. I have done this in my sendPacket_raw() method.
• In my adapted hmRadio.loop() I saved some memory because I only store different packet fragments in the circular packet buffer ( comparison based on Crc check).

All my changes are in subdir under /nano/ahoyUL. It also works on ESP8266 but via serial-IF only.
best regards
Michael (golfi200)

[lumapu]

thank you for your contribution! Really nice to see that other help to get things fixed and improved.
I like to support 328p but I don't like to have all sources twice. We have to modify the source to support this chip with the same sources.

[golfi200]

Hallo Lukas,
das ist einiger Aufwand den main branch A-nano kompatibel zu machen. Schon die ganzen debug Ausgaben brauchen zu viel RAM. Ich hatte versucht nur durch weglassen zum Erfolg zu kommen und nur main.cpp neu zu machen, aber das ging so nicht. Deshalb habe ich auch die Klassen hmRadio.h, hmDefines.h angepasst.
Naja, wenn du etwas davon verwenden kannst dann gerne.
Viel Erfolg und Grüße
Michael

[lumapu]

Hallo Michael,
ich schaue mir das nochmal an, aber hoffe du verstehst meinen Einwand. Der PR bleibt einfach, bis wir Arduino nano unterstützten. Ich habe großes Interesse daran und deshalb auch einige Strukturen seit Anfang an 'klein' gehalten, aber scheinbar nicht klein genug.

[stefan123t]

@lumapu das klingt nach genau dem was Du schon immer vorhattest. Eine Bibliothek die sowohl auf Arduino nano als auch auf ESP8266 und ESP32 läuft.
Man müsste den großen Teil der aktuell mit der WebApp und MQTT zu tun hat irgendwie sauber kapseln und den Teil der nur mit der Inverter Kommunikation und evtl noch eine Serial Port Ausgabe der empfangenen Daten zu tun hat in eine Bibliothek überführen.
Wenn wir die Serial Ausgabe dabei etwas aufräumen und evtl sogar einen Serial CLI/Command Parser anbieten, noch besser.
Ich muss mir die Code Änderungen auch mal am PC ansehen 🤤

[rosoft2013]

There would be no need for a ssd1306 screen at night.

[Flole998]

I've tested this and it doesn't work at all for me. The "original" code works perfectly fine.

[golfi200]

Hi Flole998,
does your comment refer to ahoy_nano in the dir /ahoy/tools/nano/AhoyUL/src ?
If yes, what is not working, compilation or the running app?
I have tested this with Arduino-Nano and ESP8266 board which works fine, but interface is serial-port with 57600baud only.
Nevertheless if you are happy with the main branch and initial NTP sync is no problem, then no need to use this one.

[Flole998]

I'm running on an Atmega4808 and for some reason it doesn't receive responses for like 99% of the time. I've switched to another project (DtuSim) which works better, so I'd rule out a hardware issue aswell.

[golfi200]

Its good that you receive at least once, something. So your inverter ID matches.
My latest updates are in a branch "ahoy_nano": https://github.com/golfi200/ahoy/tree/ahoy_nano/tools/nano/AhoyUL/src
I see the original contribution in the main branch is rather outdated.
The idea of my inverter polling is 7 times fast polling with 10sec interval until response received, then regular polling with 60sec interval. If nothing is detected during fast polling then I wait 20min until I start fast polling again. That is done to avoid spamming the whole night. It can be configured in config.h.

[Flole998]

I think I modified the config.h to poll with a 1 second interval.

I'm not really sure if "spamming the whole night" is actually an issue, the power consumption isn't a huge factor according to my tests, it does kinda add interference to WiFi channels but during night they should mostly be idle anyways.

[golfi200]

One sec polling interval is by far too fast. I'll make up to 10 re-transmissions if a fragment is missing and this will take up to 4sec in total. If you send faster the inverter response might never match to the last request.
So I would say 5sec polling is max, but 60sec is also sufficient because each request will be perfectly responded if system is in sync. Last not least, your neighbors will be happy, otherwise its just a Wifi jammer.