实现了消息发布订阅和数据存储，接下来就是怎么用数据了。数据展示就是可视化，可以用的软件很多，Grafana是开源软件中用得最多的（吧？）。由于用的人多，教程也多，所以只要注意以下几点就行了：

• 安装包去官网找，安装过程很详细，只是要记得一定要选择和自己主机的CPU和操作系统对应的安装包，否则安装不成功。
• 打开端口。
• 新建仪表盘时，如果SQL语句写了后可视化窗口里却空空如也，那八成是没有指定数据库，引用的表要写成XXX.YYY，其中XXX是数据库名，YYY是表名。

        EMQX接受到消息后，存储到TDengine数据库的方法就是设定规则，方法如下：

• 建立规则，用SQL语句把需要存储的消息及相应字段筛选出来（有可能接收到的是发布端的心跳包，这个是不需要存储的）：SELECT XXXX,payload.XXX,XXXXX,XXX,XXX FROM "XXX/XXX/XXXX" WHERE is_null(payload.XXX)=false
• 在规则的动作输出中选择TDengine，写一条在数据库中插入数据的SQL语句：insert into XXXXX using XXX tags('XXX','XXX') values (${XXX},'${XXX}', ${XXX}, ${payload.XXX}, '${XXX}'),第一个字段记得永远要用时间戳，字段是int或者float的，不需要加''。
• 在规则建立页面有调试功能，可以在设定规则后，用MQTT.fx发布数据，然后观察是否成功存储到TDengine中，以此来判断和排除语法错误。
• TDengine是时序型数据库，规范建表的方法是先建超级表stable，需要存储的字段都在超级表中事先确定，然后每个设备用一个新表table存储数据，表会继承超级表的字段，不需要再次定义，但也意味着不能随意修改增减，所以超级表设计时一定要考虑周全，否则只能逐个增加超级表的字段。
• 规则的动作输出也可以选择为消息再输出，把筛选出来的消息以另外一个主题重新发布出去。
• 同理，当规则的SQL语句中增加了数据的比较和筛选功能（如数值大于或小于某个设定值时），再设定一个消息再输出，就实现了报警功能，这样做的好处是规则的设定完全是在服务器端，前端硬件设备不需要做任何设定，这样灵活性无疑大了很多。筛选出来的数据同时也可以存储到TDengine中，实现报警数据的记录。

        Arduino调试过程中，会出现一些匪夷所思的问题，表面上看来是闹鬼，其实都各有原因，只不过原因隐藏得比较隐秘。比如：

• 用UNO调试一个电路，当单独挂载一个SSD1306的IIC屏时，使用例程和自己的程序都正常，但一旦放到一个有三个IIC器件的系统中就始终无法编译通过，想过可能是地址的问题，但查下来地址都不重复，最后发现是通常用的SSD1306库文件消耗内存太大，UNO这样的内存有限的MCU当只运行这个库时没有问题，一旦加载的库多了，内存就不够分，体现在在编译显示分配失败。解决办法是找一个内存消耗小的库，或者换成MEGA2560，显然前者更有可行性。
• 一个串口屏的应用，接收到信息后报警，用一个按钮中止报警修改报警背景颜色，结果程序编译完成后其他功能都正常，唯独串口屏无法显示设定的初始界面，总是一晃就变成空数据界面，怎么调整程序都不行，最后发现是按钮对应的IO口异常，虽然软件做了上拉，但高电平时只有2V，造成进入LOOP循环后程序认为按钮已经被按下，串口屏自动显示报警中止后设定的画面，此时又没有数据，只能显示一个空数据画面，换一个IO口就一切正常了。
• Arduino里将时间戳转换为正常的日期和时间格式，网上的Arduino time库现在的IDE用不了，试验了安装time库可以进行转换，然而转换出来的日期和时间始终不对，最后发现这个库的转换功能只能用于转换10位的时间戳，如果你用的是13位的时间戳，那必然不对，需要先将13位的时间戳截取为10位，才能正确转换。

        UsartGPU串口屏是最常用的串口屏，最近在应用过程中遇到问题，串口语句在GPUMake中显示正常，但移到Arduino后就始终无反应。经过长时间排查，直到查阅了厂家网站www.ai-diy.cn上的文档才发现问题所在，这几个坑真不容易注意到，下次应用一定要注意：

• 要在串口屏上显示汉字，不能在Arduino IDE中直接引用汉字，因其编码格式为GB2312，而串口屏需要ANSI格式，解决办法是在记事本里以ANSI格式新建一个hz.c，里面写一条语句 const char hz[][32]={"XXX","XXX","XXX",......}，每个字或每个词、短语作为数组元素添加其中，注意数组的长度要因放入的汉字多少而定，一个汉字需要两个字节。将其放到ino文件的相同目录中，在编写Arduino程序时将其纳入：#include "hz.c"，在发送时用hz[X]引用相应汉字。
• 发送一堆串口命令时，一定要在最后一条串口数据发送时加上换行符：Serial.println("XXX");否则串口会认为命令还没有接收完毕，不会有任何动作。
• 如果屏上显示有稀奇古怪的问题，一定是在串口数据编码过程中出现了格式问题，比如少了一个），引用hz[X]时要在其前后加上'。
• 串口屏使用的是GB2312编码，Arduino用的是UTF-8编码，后来发现一个不需要很麻烦的办法：在Arduino中安装UTF8TOGB2312的库，就可以在程序中实时转换编码，实现串口屏的中文文字实时显示。

        搭建方案是让DeepSeek帮助制定的，技术路线是：EMQX作为MQTT服务器，通过设定规则和连接器将接收到的信息传送给TDengine时序数据库存储数据，用Grafana作为数据可视化工具。安装调试过程中颇掉了不少坑，记录如下，以后再部署时避免弯路。

• EMQX与TDengine安装时注意选择与操作系统适配的版本。
• TDengine安装后，要启动taos适配服务：systemctl start taosadapter，否则与EMQX的连接无法成功。
• 使用公众云平台部署时，EMQX要打开1883，18083等端口，TDengine要打开6041端口。
• EMQX里设置规则时，SQL的语法与MY SQL的语法并不完全一致，有的语句和功能无法直接使用，要查阅它自己的SQL语法手册，TDengine同理。
• EMQX和TDengine在同一台服务器上部署时，如果不使用Docker,连接器地址要选择127.0.0.1:6041，用Docker部署时则用相应容器的地址。
• MQTT消息的格式一般会用JSON格式，同一台终端可能同时会发送心跳包（特定字符）以维持连接，在转发存储时设定规则，可以在SQL语句尾部加上 WHERE is_null(payload.XXX)=false 以过滤掉非JSON格式包。
• TDengine在创建数据库时，一定要加上数据保留周期 KEEP 365，这是保存一年，如果不设定，默认保存10年，服务器空间压力太大。要加上允许修改的参数 UPDATE 1，否则只能整个表删除。
• TDengine建数据库后先建超级表，把需要记录的字段设定后再建子表，子表继承超级表结构，只用设定TAGS来说明终端的位置和类型等即可。
• 虽然有人物联网的CAT-1模块在透传模式时只用向其发送JSON数据，但在EMQX接收时会收到包括时间戳、用户ID、QOS等信息在内的完整数据包，可在EMQX规则设定中打开调试模式试验查看。数据戳来源可解析收到的payload.timestamp，也可以直接引用函数NOW。

        用Server酱来推送domoticz系统里的天气预报、家中温度实况等已经有几年了，一个星期前突然收不到推送信息，诡异的是从中国气象局网站抓取的卫星图像的推送正常，但就是domoticz的推送异常，在笔记本上运行了下脚本是正常的，可以收到推送，但在树莓派上SSH操作就是返回400异常。反复试验，再仔细看了Server酱的官网说明，猜测可能是urlencode编码的问题，在脚本中加了一段urlencode编码的语句，上传树莓派后运行正常。要注意的是python中urlencode编码需要先建字典，将url中的参数以字典方式呈现，然后转换为urlencode编码，再与url的网址部分相加，此时向网站发送就一切正常。猜测是Server酱的后台代码进行了微调造成了这种情况的发生。自己做的系统就是这样，需要不断修复发生的问题，但是规范代码确实很重要。

        2022年自制了魔镜固件，用chromium浏览器，koisk方式全屏显示，从和风天气拉取天气预报，从RSS源拉取新闻速报和名人名言，从家里的Domoticz拉取室内温度等实时数据，反复调整HTML页面，总算达到一个比较和谐美观的效果。今天重新上电，发现数据不能更新，无WIFI，必须用有线连接，经查原因如下：

• 不能更新数据的原因是和风天气预报API发生变换，以前是V5版本，现在用的是V7版本，指令模式不同
• 不能更新数据的第二个原因是无法从Domoticz服务器拉取实时数据，因为之前增加了Docker用来搞内外网穿透，为了安全设置了用户名和密码，这时再读取就会发生错误，查Domoticz文档改用增加header的方式，用户名:密码转换为Base64模式后，增加‘Authorization’：‘Base XXXXXXX......’的头，这样就能读取到数据了

• WIFI不能使用的原因不明，用了多种方法都没有用，最后是修改/etc/network/interfaces，改为如下，要注释掉wpa_supplicant.conf那一行。

  iface lo inet loopback
  
  iface eth0 inet manual
  
  auto wlan0
  allow-hotplug wlan0
  iface wlan0 inet dhcp
  wpa-ssid "MySSID"
  wpa-psk "topsecret" 

• 退出koisk全屏模式的快捷键是ctrl+w

        已经可以申请DXCC100奖状了，下面的目标是DXCC挑战奖状，估计要好几年才有可能了。

        JTDX的操作需要频繁动用鼠标，而抓通联稀有DXCC的机会很多时候用鼠标就不够看了，于是动了用快捷键盘的心思。自定义键盘很多，大多是若干个按键组合在一起，高级一点的按键上有LCD屏幕显示图标方便记忆，但还是一眼看上了tourbox，看到曲线外壳、貌似杂乱无章排布的旋钮、滚轮和按键，直觉就感觉用起来一定很顺手。这个牌子的lite性价比最高，到手后设置试验后果然感觉很好。各种软件都可以使用，有键盘快捷键的，可以直接把快捷键映射到按键、旋钮或者滚轮上，没有快捷键的，也可以通过记录宏实现下拉列表框、滚动选择等操作。
        JTDX的TourBox设置:

• 按下旋钮，打开频段选择下拉框，滚动滚轮选择频段，按下滚轮切换到指定频率
• 按下横键切换到TX6，即CQ信息
• 按下长键启动发射，按下短键中止发射
• 按下Tour键清空信息窗口
• 按下c1键发射接收频率下调1Hz，按下C2发射接收频率上调1Hz

        FT8已经是短波数字DX的主流，很好地解决了短波业余无线电活动中一些无法回避的问题：在SSB上吼叫字母解释法对很多人是很尴尬的事情；CW的自学难度极大；城市中架设八木简直不可能，就算架设一条最不显眼的偶极天线或端馈天线都要面对邻居的举报和纠纷；城市中的高电磁干扰环境让SSB和CW的DX难度大了好几个数量级......如此这般，以时间和低码率换DX的数字通信优势就彰显出来，小功率即可实现全球通联，灵敏度低至-25dB仍可解码的FT8就取代其他格式成为如今短波数字通信的主流。JTDX作为FT8的操作软件，自动化程度是很高的，但是自动化程度再高也需要人工操作，而且操作技巧的好坏直接影响到FT8的通联效果和效率。FT8的使用可以看ZL2iFB写的FT8操作指南，下面是我在JTDX使用过程中的一些经验：

• 一定要配套使用Gridtracker，设置好lotw，发现CQ时可以在地图上点击发出CQ的QTH方块，从弹出的CQ方信息可以看出对方是否关联了lotw账号，如果lotw下方没有打钩，基本上不用指望能在lotw上获得交叉确认，这对收集DXCC实体数量的HAM来说不是好消息，或者说，这也可以作为你是否决定与其通联的一个重要考量因素。
• 一开始回复别人的CQ确实很方便，等到用的时间足够长了，弹出来的CQ都是你通联过的时候，其实也不用在每个频道上苦苦寻找新CQ，自己发出CQ等着别人应答好了，我将其称为钓鱼模式。有时，能钓到意想不到的好鱼。
• 发射过程中只要发射开始没有超过1/5,即时更改发送内容对方也可以准确解码，但是尽量不要在发射过程中更换发射频率，这种情况下几乎难以准确解码。
• 有时候在不太干净的频道位置发射对方反而能够解码，所以在干净的位置发射没有人回复的时候可以选个不太干净的地方重新试验一下。你在本地看到的干净的频点，可能是几千公里以外意图通联对方的拥挤不堪之处。
• Gridtracker上的QTH方块在不同纬度的形状不一样，靠近赤道时是宽长高短的长方块，越靠近两极高度越高，所以小长方块、大正方块都是一个QTH的尺寸，我估计是墨卡托投影的缘故。
• 要想获得lotw的交叉确认，只与一个DXCC实体通联是远远不够的，有的HAM没有关联lotw，有的HAM虽然关联了lotw但是你天知道他什么时候才会上传一次通联日志，所以只要还没有交叉确认过的DXCC实体，新呼号出现时就一定要呼他、呼他、呼他。
• 单向传播经常发生，所以有时候你能收到对方信号，但无论你怎么更换频点，对方永远听不到你。换个频道，找个其他目标通联吧。
• 不要总是发射，要经常停止发射看一看发射周期内有没有什么新信号，有时候过段时间就切换下奇数偶数周期也是有效的观察办法。
• 学会换位思考。不是仅仅我们自己需要新的DXCC，全世界的其他HAM可能也需要我这个DXCC。所以，经常CQ一下，及时回应别人的呼叫，即使你已经有了他的DXCC，每天上传lotw日志，可能正有HAM在焦急等待你的交叉确认呢。

        本文将不定期更新。