The email plugin was still using globals for tracking
the check_email_delay as well as the config. This
patch creates a new singleton thread safe mechanism for
check_email_delay with the EmailInfo class.
This patch completely refactors and simplifies how the clients
are created and used. There is no need now to have a separate
KISSRXThread. Since all the custom work for the KISS client is
encapsulated in the kiss client itself, the same RX thread and
callback mechanism works for both the APRSIS client and KISS Client
objects. There is also no need to determine which transport
(aprsis vs kiss) is being used at runtime by any of the messages
objects. The same API works for both APRSIS and KISS Client objects
Started noticing that aprs-is keepalive messages just stop
getting sent. This causes aprsd to basically disconnect from
the APRS network. Added a check into the KeepAlive thread to
restart the aprs-is connecter if the last time we got a keepalive
from apris is > 5 minutes.
This patch enables the ability for plugins to return:
* string
* list of strings
* message object
* list of strings and message ojects
Each string will be encapsulated in a message object prior being sent.
each message object will be sent directly.
Each list will be iterated over and processed according to the above 2
options.
This allows the admin interface to see which plugins are registered and
enabled. Enabled is a flag that is set in the setup() method of the
plugin. This gives the plugin developer a chance to disable the plugin
if something isn't right at setup time. This allows aprsd to ignore
plugins that are registered but not emabled.
If the logging queue gets full, due to a maxsize being set,
then any further logs will result on lots of errors being dumped
to stderr as the queue is full.
This patch adds a live view of the aprsd logfile in
the admin ui. This uses a new Log QueueHandler and the
threads.logging_queue to push log entries into a queue.
The flask websockets server will push those log entries up
to a connected client browser.
When the admin user users the web ui to send a message
a new client instance is created with login credentials for
that particular message. This patch ensures that send_direct
uses that client.
This patch adjusts the py3-email-validation usage. Since we
upgraded to 1.0.2, the signature has changed. This patch adjusts
the signature usage so it works again.
This patch adds APRS KISS connectivity. I have tested this with
a running Direwolf install via either a serial KISS connection or
the optional new TCPKISS connection, both to Direwolf.
This adds the new required aioax25 python library for the underlying
KISS and AX25 support.
NOTE: For the TCPKISS connection, this patch requires a pull request
patch the aioax25 library to include a TCP Based KISS TNC client to
enable the TCPKISS client So you will need to pull down this PR
https://github.com/sjlongland/aioax25/pull/7
To enable this,
Edit your aprsd.yml file and enable one of the 2 KISS connections.
Only one is supported at a time.
kiss:
serial:
enabled: True
device: /dev/ttyS1
baudrate: 9600
or
kiss:
tcp:
enabled: True
host: "ip address/hostname of direwolf"
port: "direwolf configured kiss port"
This patch alters the Message object classes to be able to
send messages out via the aprslib socket connection to the APRS-IS
network on the internet, or via the direwolf KISS TCP socket,
depending on the origination of the initial message coming in.
If an APRS message comes in via APRS-IS, then replies will go out
APRS-IS. IF an APRS message comes in via direwolf, then replies
will go out via direwolf KISS TCP socket. Both can work at the same
time.
TODO: I need some real APRS message packets to verify that
the new thread is processing packets correctly through the plugins
and able to send the resulting messages back out to direwolf.
Have a hard coded callsign for now in the kissclient consumer call,
just so I can see messages coming in from direwolf. I dont' have an
APRS capable radio at the moment to send messages directly to direwolf.
Might need to write a simple python socket server to send fake APRS
messages to aprsd kiss, just for finishing up development.
APRSD No longer follows the black code styling. Black just sucks
due to it's completely unreadable code for functions with long
parameter lists. This patch removes the code style badge from
the README.rst
Since all outbound messages have a send() method that starts
a separate there, there really is no reason for the transmit queue
thread at all. All it did was get a message from the queue and then
call send on it, which would start another thread. This removes that
intermediate TXThread. When you want to send a message just call
send() on the message object.
This patch updates the select timeouts for threads. This allows
threads to exit quicker when user hits CTRL-C.
Updates the KeepAlive Thread to include total packets.
This patch adds plugin rx/tx processing of packets.
This tracks how many messages a plugin processes (recieves) and
how many packets result in a plugin sending a message out.
This patch also adds a new plugins tab on the admin page.
This patch updates the APRSDPluginBase class to include
standard methods for allowing plugins to create, start, stop
threads that the plugin might need/use. Also update the aprsd-dev
to correctly start the threads and stop them for testing plugin
functionality.
Also added more unit tests and fake objects for unit tests.
This patch refactors how the recieved message processing happens.
We now handle all incoming packets the same. Removed the notification
thread to handle the watchlist packets. This is now done with a
unified plugins architecture that allows different capabilities
via the new plugin structure. All packets sent to us will be
sent through all of the plugins. It's the plugins job to decide what to
do with that packet or ignore it.
Email is no longer a special case for the most part. All email
functions have been migrated to the EmailPlugin, including starting the
EmailThread, which works in the background to check for new emails and
send those to the registered callsign. The EmailPlugin now starts the
EmailThread itself.
All plugins are now build on the new APRSDPluginBase which has a common
set of features. The APRSDPluginBase calls self.setup() upon creation,
which allows all plugins to do whatever they want for initiali startup.
The EmailPlugin uses setup() to start the EmailThread if email is
enabled.
