This week, as a follow-up to Remote LLM RAG this post, I have been working on additional RAG (Retrieval Augmented Generation) functionality for the rXg's built in LLM solution. This includes 2 components:
Recently my boss gave me an interesting challenge: Make our LLM (Large Language Model) system smarter by giving it access to remote data feeds.
LLMs are very good at knowing about events that are in their training data. But they are not able to know about new information.
RAG (Retrieval Augmented Generation) is a technique of finding contextually relevant data, based on the users' query and including it in the context sent to the LLM, so that the LLM can forumulate an up-to-date response, or a response that is informed by data beyond its training data.
Continue reading for a concise explaination of how to accomplish this magic...
Location services are the ways that location data is used by the rXg to enhance the experience of the Operators and the Users.
Config templates are a powerful way of encoding business logic in a clear and concise way so that it can be applied programmatically to the rXg. These are just my notes about some features, for official documentation please see Config Templates
In my opinion, true mastery of config templates comes from combining 3 things.
A mastery of how config templates work syntactically 1.1 ERB Expansion 1.2 YAML Ingestion
A wide understanding of the vocabulary of what can be configured via config templates, ie all the scaffolds.
The ability combine the first 2 within the context of a particular deployment or operational plan
For the teaching I am going to focus primarily on #1 because that is something that can reasonably be learned in one blog post or short teaching session.
A single template could configure everything an rXg needs from layer 1 to layer 7. For example, here are just some things that can be configured by a config template:
The rXg's Certificate Management feature is one of my favorite things about it. as someone who has managed ssl/tls certificates on many different platforms at many different times, including manually, I absolutely love the convenience of this feature. It pairs AMAZINGLY with the previously discussed http virtual hosts feature, and in my post about how I set up this blog.
In this post will lay out several facets of WiFi KPIs that I plan on diving into in greater detail in the future. I hinted at this already in my mcs_index post.
Many different areas of business and technical operations use KPIs as feedback for higher order decision makers to know if things are going well or not. In the context of commercial WiFi, the primary goal of KPIs is to find out if a customer is having trouble before a ticket lands on the help desk.
In general KPIs encompass any data relevant to the 802.11 connections. In practice this amounts to mainly RSSI, SNR, Noise Floor, Channel Utilization and throughput.
Integrating a PMS system with your rXg is a great way to increase its functionality by having it query a third party for information. This is incredibly useful for onboarding authorized guests, be they paid or unpaid.
In this post, I will lay out some of the deeper details of configuring the rXg as a WISPr provider, intending to cover both TP-Link's Omada Pro CBC and RUCKUS's vSZ.
This will be a particularly rXg-heavy post, so if you would like to follow along at home please check out our free rXg program, where you can download and install rXg on your own hardware.
Configuring a RUCKUS site to use WISPr with a RUCKUS vSZ is easy.
Coming from a freelance web developer background, the HTTP Virtual Host feature of the rXg was the first thing that really floored me. A lot of my prior work had do do with getting my clients' sites working on docker -based platforms like Heroku, and eventually hosting environments of my own creation and specification.