Been busy with my startup company for a while but found some time to fix some bugs. I don't know of any remaining bugs so I think this is pretty close to a v1.0, but prove me wrong :).
This version is feature complete, just need to find remaining bugs.
Detailed information and installation instructions can be found here:
http://www.trevorsbench.com/meshchat-messaging-for-mesh-networks/
**** Action Script support is now ready for testing. More info here: http://www.trevorsbench.com/mesh-chat-action-scripts/ ****
Installation is the same for v0.7b7 as in the blog post link above. Doc and blog post will be updated when beta is finished. Just change the files for these ones:
AREDN Node: https://s3.amazonaws.com/aredn/meshchat_0.7b7_all.ipk
Raspberry Pi: https://s3.amazonaws.com/aredn/meshchat_0.7b7_all.deb
This is a BETA version. Bugs guaranteed. Please try it and let me know what you find. This will place nicely with v0.6. v0.6 will display all messages regardless of channel from v0.7. You can install this version right over top of any existing version of meshchat.
**** Raspberry Pi / Debian / Linux Users ****
After you install the package you need to edit this file:
/usr/lib/cgi-bin/meshchatconfig.pm
These 2 lines at the bottom:
our $pi_zone = 'MeshChat'; our $local_meshchat_node = 'k7fpv';
$pi_zone is the zone that mesh chat should sync with. Zones are described in the release notes below.
$local_meshchat_node is a AREDN node on your mesh running mesh chat v0.7. The Pi queries this node to get the node list it should poll for the zone it belongs too.
Once those config file changes are made, restart the daemon:
sudo /etc/init.d/meshchatsync stop sudo /etc/init.d/meshchatsync start
So to run mesh chat on a Pi you need to have the same version of mesh chat installed on a AREDN node somewhere on your mesh.
**** If you change your Zone on an AREDN node it is recommenced that your reboot the node for it take effect. ****
v0.7b7 Release Notes:
Fixes special characters not encoding into JSON
Adds random number to default service announcement to prevent message database problems on first install
Layout fixes
File download and url fixes
v0.7b5 Release Notes:
Use proper port number for file sharing links
Fixed race condition with OLSR and zone discovery, this was causing sync issues
Fix init.d stop to not use killall
Mobile layout fixes
Item counts at top of tables
v0.7b4 Release Notes:
UI queries the message db version and only downloads when it does not match what it has loaded. This dramatically reduces the network traffic and load on the node.
Tighten up white space to bring messages above the fold
Added message search
Change file list sync to use one file per node vs a merged db
v0.7b3 Release Notes:
Action Scripts ready for testing
Ctrl-Enter will send a message vs clicking the Send button
v0.7b2 Release Notes:
v0.7b1 Release Notes:
Zones: You can now have segmented mesh chat databases on a single mesh. Mesh chat looks up the service name it has been given in OLSR. The default is MeshChat. It will only sync with other nodes / pi's that share the same service name. Now you can setup SoCalMeshChat, UtahMeshChat, etc and only the nodes with the same service name will sync with each other. Now when you tunnel into another mesh you won't dump your whole message db into their mesh chat, unless of course you share the same service name.
Change max message db size from bytes to 500 max messages: There was some issues when the db would get full, the whole db would get sent over every sync since the version did not match. To make things simple and robust all message db's are limited to 500 messages so when it is full, the quick version check works properly. Message db's are now stored in sorted order as part of this change too.
Added channels: You select or create a new channel when you send a message. You can select the drop down filter at the top of the message pane to select which messages to display. All message db's contain messages from all channels. They are filtered client side with the display filter.
Action scripts: Action scripts are only supported on the Pi version. This is pretty much done but needs more testing. If you feel adventurous you can add a line in /etc/meshchat_actions.conf You can read the comments in that file on what kind of matches you can do. I have a SMS gateway and archive working. More details and code to come.
Seeing node to node not updating reliability. And status not keeping updated like before.
Use to get good connectivity with nodes many hops away, now not good to a next node.
Update:
Changed back to, v0.7b5 having same issue so does not seem to be a bug introduced in v0.7b7.
Thinking that may have updated to ARDEN 3.16.1.0 and mesh chat v0.7b5 at the same time, so may be ARDEN 3.16.1.0 affecting mesh chat.
As a test I am logged into 3 mesh chat nodes at same time, the "Mesh Chat Users" windows that show users, are not updating consistently.
Ron
All nodes ARDEN 3.16.1.0
2 Gig rocket DTD to 5 Gig NanoStation, RF to 5 Gig NanoStation.
Changed all back to v0.7b5, no inprovement.
Have logged into 3 chat nodes at same time, user lists and message sync have issues.
Ron
See image
Running three nodes as an island, MeshChat nodes seem to run normally.
Changed MeshChat to a different name to isolate the nodes the rest on network.
Ron
The node API install also works ok with my Pi.
A few of us are meeting tomorrow so would like to understand rev. 07b7...
Question - If I'm reading right, one of the M2s in our mesh has to have 07b7 installed? Even if everyone is running behind RPi?
Question - Don't understand how we determine what to put in the pi_zone...
Question - the local_meshcat_node is the M2 that is running meshchat?
Thanks, and 73, Patrick
Great little utility and well done!!! thanks
73! David KG5EIU
The issue: We managed to "break" MeshChat discovery on our mesh for my node, when another node was reconfigured and eventually removed, and had a very difficult time finding it. The reason was because of the need for $local_meshchat_node in the /usr/lib/cgi-bin/meshchatconfig.pm file. The use of $local_meshchat_node puts in an (un-necessary) dependency on a Ubiquiti node running MeshChat in your system, and also will break if that node disappears, is reconfigured, or otherwise is unreachable.
In our case, what happened, is I set up my MeshChat node on a Linux machine (rather than Ubiquiti) due to the out-of-memory issues.
When configuring it, I pointed to an active MeshChat node, which was working when I installed.
However, that MeshChat node was (unbeknownst to me) taken out of service -- which stopped Synchronizing my MeshChat node.
I thought it was a version problem, and upgraded to 0.7b7... which reset my $local_meshchat_node to localnode -- my own Ubiquiti, *NOT* running MeshChat.
The result: nothing worked.
The fix was to find *another* MeshChat node and reset $local_meshchat_node.
In debugging this, I figured out that there is a dependency to have at least one Ubiquiti-installed MeshChat in order to run http://$local_node:8080/cgi-bin/meshchat\\?action=hosts_raw and discover the hosts.
The (long winded) request: instead of using meshchat on a node to do the discovery, use OSLR and do a discovery of nodes with MeshChat installed, and poll the nearest node for hosts -- rather than requiring this to be tied to a specific node. Worse comes to worse, MeshChat could query localnode and find all connected nodes, and probe each with a http://$each_node:8080/cgi-bin/meshchat\\?action=hosts_raw -- or even request the message file directly. The current requirement of having $local_mesh_node creates an un-necessary dependency and single point of failure, IMHO.
A possible discovery routine:
1. Query http://localnode:8080/cgi-bin/mesh or appropriate sysinfo.json call
2. Extract list of nodes from the table.
3. Poll each node for MeshChat, including advertised service nodes (ie for RPI nodes under a AREDN node).
4. Use that resulting list as your node list
5. Repeat as necessary on a polling interval for changes
Thanks!
Ben
KK6FUT
http://www.aredn.org/content/patch-run-meshchat-raspberry-pi-without-ins...
Thanks!
Ben
KK6FUT
Realistically adding a controlled API like Trevor's add on API package does is the best way around this. In this way Trevor knows what to expect and can transfer it in a machine friendly way.
Perhaps in future similar information may be available in a stock resource, but it just isn't there out of the box at this time.
If node information ever makes it into syslog.json that would be better than an add-on API. I know that to map nodes externally (without screen scraping) you really need to have a similar interface to node information available too.
Ben
KK6FUT
ps. If someone did want to implement something which used the inferior "screen scraping" method, which is subject to people modifying the GUI, et al., here's the perl snippet code.
my $url = "http://".$start_node.":8080/cgi-bin/mesh";
my $html_string = get($url);
$te = HTML::TableExtract->new( headers => [qw(Remote)] );
$te->parse($html_string);
# Examine all matching tables
foreach $ts ($te->tables) {
print "Table (", join(',', $ts->coords), "):\n";
my $skip = 0;
foreach $row ($ts->rows) {
if (!$skip) {
my $data = join(',',@$row);
$data =~ s/^\s+|\s+$//g;
$data = join '', split ' ',$data;
if ($data eq "Previous Neighbors") {
$skip = 1
} elsif (($data ne "")&&($data ne "1")&&(length($data)>3)) {
$data =~ s/^\s+|\s+$//g;
print "add:", $data, "\n";
#push (@foundnodes, $data);
$foundnodes{$data} = 1;
}
}
}
}
David
Thanks, David
KE6UPI