Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Ahoy Arduino nano Port #478

Open
wants to merge 20 commits into
base: main
Choose a base branch
from

Conversation

golfi200
Copy link

@golfi200 golfi200 commented Dec 5, 2022

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
Copy link
Owner

lumapu commented Dec 12, 2022

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
Copy link
Author

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
Copy link
Owner

lumapu commented Dec 18, 2022

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
Copy link
Collaborator

@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 🤤

@stefan123t stefan123t changed the title Ahoy nano Feature Request: Ahoy Arduino nano Port Jan 12, 2023
@stefan123t stefan123t added enhancement New feature or request help wanted Extra attention is needed labels Jan 12, 2023
@rosoft2013
Copy link

rosoft2013 commented Jan 25, 2023

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

@Flole998
Copy link

Flole998 commented Jun 1, 2023

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

@golfi200
Copy link
Author

golfi200 commented Jun 5, 2023

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
Copy link

Flole998 commented Jun 5, 2023

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
Copy link
Author

golfi200 commented Jun 5, 2023

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
Copy link

Flole998 commented Jun 5, 2023

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
Copy link
Author

golfi200 commented Jun 6, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants