无人自助台球系统实战：IoT硬件、计费引擎与小程序全解析

做无人自助台球这套系统很多人第一反应是做个扫码开台的小程序不就行了。真下场做过一轮之后才发现台球这个场景比想象中要复杂得多灯光要随开台自动通电开锁要防掉线计费要防争议老板要看实时的经营数据还得让用户从约球——到店——开台——计时——结账——离店这条链路全程无感。我这次上线的科技领航共享无人自助台球软件本质上就是把一整套IoT硬件、计费引擎、用户端小程序和商家管理后台串起来做成一个真正能落地运营的SaaS产品。这篇文章我会把从方案选型到核心功能实现、再到部署和排障的完整过程摊开来讲适合正在做同类无人自助项目、或者准备把传统球房改造成24小时自助模式的朋友参考。1. 项目定位与整体方案拆解1.1 目标场景与商业闭环做无人自助台球不是单纯省一个人工那么简单。传统球房最大的成本除了房租就是夜班值守而台球消费的高峰恰恰集中在晚上六点到凌晨两点。如果能把这段时段的看店人力去掉球房就具备了24小时营业的可能坪效和使用率都会明显提升。我这次软件的服务对象是两类人一类是球房老板他们要的是省人、增收、管账清晰另一类是打球用户他们要的是到店即打、无人打扰、计费透明。这个软件要解决的就是让这两类人通过一套系统完成交易闭环。整个商业闭环是用户线上约台和支付押金到店扫码开门控制器通电亮灯计时开始离店自动结算平台与商家按比例分账。1.2 技术选型的关键权衡无人自助台球场景的设备端核心是一个嵌入式控制器加门锁控制器需要联网、接收云端指令、驱动继电器通断还要上报设备状态。当时我考虑过几套方案方案A纯蓝牙Mesh方案用户到店通过小程序蓝牙连接设备开锁。好处是省流量、不需要球房有外网坏处是远距离管理和后续升级功能受限老板看不到实时在线状态。方案B纯MQTT上云方案所有控制器通过Wi-Fi接入公网云端统一下发指令。好处是无论人在哪里都能管控坏处是对球房网络稳定性要求高断电断网的极端情况需要做好本地兜底。方案C本地网关加云端的混合架构。控制器走局域网网关网关负责本地策略缓存同时对接云端服务。造价稍高但可靠性最强。最后我选了方案B为主、配合本地策略兜底的做法。原因很直接自助台球的核心价值就是远程化、无人化IoT设备的在线率和可控性必须优先保证。Wi-Fi智能插座级别的硬件成本能控制在较低范围大多数球房本身也有宽带和路由部署难度低。对于断电、断网这种极端情况我在控制器固件里做了开锁状态保持和离线缓存这个后面在设备容错部分细讲。1.3 与纯扫码计时方案的差异点市面上一部分所谓自助台球其实是半自助一套扫码计时系统加一个机械锁用户扫码后手动开灯离店后手动关灯。这套东西便宜但体验割裂灯光忘关、计费超时都是常见投诉。我这次做的共享无人自助强调的不是扫码付款开台这一个点而是全链路无人干预。从门锁、灯光、计费、异常报警到离店断电全自动完成。灯光和门锁必须和订单状态强绑定订单开始继电器吸合灯光通电订单结束继电器断开灯光熄灭。这套逻辑看着简单实际涉及订单状态机、设备状态同步、掉线重连、防误判等多层问题也是后面要花最多篇幅来讲的部分。2. 核心功能模块与关键技术实现2.1 硬件控制层IoT终端与开锁/通电逻辑硬件控制层是整套系统的手和脚。我使用的IoT终端核心是一块ESP32模组加两路继电器一路控制门锁电磁铁一路控制台球桌上方灯组的电源。模组通过Wi-Fi连接云端MQTT服务器同时保留了本地HTTP接口用于调试。开锁通电的核心流程是用户在小程序下单并支付押金后云端订单状态变为待开台。小程序端调用开台接口云端下发开锁通电指令到MQTT主题。控制器收到指令后先驱动门锁继电器吸合1.5秒让电磁锁弹开再吸合灯光继电器并返回状态上报已开台。云端收到状态上报后将订单状态更新为进行中并开始计费计时。这里有个特别容易踩坑的地方电磁锁的电流冲击和继电器的寿命问题。如果频繁通断继电器容易粘连导致锁体一直保持在开启状态。我在固件里做了保护逻辑每次开锁后强制延时5秒才能再次触发同时每个订单最多允许三次开锁操作超过次数会自动触发异常工单上报。2.2 计费引擎与金额精度处理台球计费并不是简单的每分钟多少钱。实际场景中大多数球房区分工作日、节假日、峰时、谷时还有会员价和非会员价部分球房还叠加第一小时xx元、续费每小时xx元的阶梯价。用传统定时任务去逐个订单算费数据量大且容易出错所以我做了一个独立计费引擎。计费引擎的核心是一个按分钟推进的定时任务它只负责计算当前时间点这个订单应该扣多少钱然后把金额追加到订单累计费额中。计费规则全部配置化运营人员在管理后台可实时调整价格策略无需发版。金额处理上必须讲一个细节所有金额字段在数据库中一律使用整数分存储禁止使用浮点数。微信支付和支付宝支付的单位都是分计费引擎在计算时也用整型毫分或分避免浮点误差导致的多扣一分钱的客诉。比如某球房工作日第一小时价格为28元续费价格为15元每小时前60分钟每分钟扣除0.4667元累计显示四舍五入到分。第61分钟起每分钟扣除0.25元。我在实现时不是用每分钟扣一次的物理时间片而是用按秒统计、按分累计的方式每分钟结束时计费引擎读取该分钟内的实际时长乘以单价后累计到费额字段。这样即使出现网络延迟或服务重启补算逻辑也能保持精准不会因丢秒造成少扣费也不会出现用户申诉多打了几分钟多扣了钱的问题。还有一个坑掉线期间的计费。用户在开台状态下如果网络中断控制器会保持灯光和锁体状态不变但云端无法计时。我的处理方式是控制器本地记录开台时的时间戳恢复网络后立即上报离线期间的时间段云端补算该段计费。这个补算逻辑要求控制器的本地时钟尽量准确所以固件里每次连接MQTT时都会同步一次NTP时间。2.3 用户端小程序与会员体系用户端我选择了微信小程序核心原因是微信生态在台球人群中的渗透率极高小程序无需下载安装用户从扫码到开台可以控制在15秒以内。小程序主要包含以下页面和功能首页附近球房列表、距离排序、营业状态、在线空闲球台数。球房详情台型列表中式八球、斯诺克、九球等、不同时段价格、环境照片、用户评价。选台开台选择空闲球台确认计费规则支付押金或购买次卡后开台。订单中心进行中订单展示剩余时间、累计费用历史订单展示消费明细和发票入口。会员中心余额充值、优惠券、会员等级、邀请有礼。这里的会员体系不是简单做个充值送金额而是和运营策略深度绑定。比如新用户开台享首单减免次卡用户优先预定热门台位会员等级决定折扣和信用免押额度。信用免押这块我接入了微信支付的支付分能力信用分达标的用户可以直接开台不需要预先支付押金离店后自动从余额或绑定扣款渠道扣除费用。这个功能对用户体验的提升非常明显实测数据显示信用免押的开台转化率比押金模式高出三成以上。小程序端还需要特别注意GPS定位权限和球房位置的反向校验。用户开台后如果跑到距离球房1公里外系统不会立即取消订单但会推送提醒防止有人远程下单实际占台不用。2.4 管理后台与经营数据看板管理后台是老板们每天都要看的页面功能上我把它拆成四大块设备管理、订单管理、营销工具和数据看板。设备管理这块老板可以在后台看到每台球桌的在线状态在线、离线、使用中、空闲、故障锁定。出现离线或故障时后台会高亮告警同时推送微信模板消息到老板手机。我做过一轮优化故障告警不是只看是否在线而是结合心跳间隔、继电器状态、订单占用状态综合判断。比如一台球桌处于在线状态但连续30秒没有心跳系统先预警弱网若超过3分钟没有心跳则判定离线并自动冻结该球桌的下单入口防止用户下单后无法开台。订单管理这块除了常规的订单查询和退款操作我加了异常订单处理队列。所有设备无响应、开台超时、结算失败、金额不一致的订单都会自动进入这个队列按紧急程度排序。老板只需要按顺序处理不需要翻遍所有订单找问题。数据看板是我比较自豪的部分。除了营收、单量、客流趋势这些基础数据我额外做了台时利用率和时段热力分析两块。台时利用率指的是每个球台的每小时实际被占用时长与全天可运营时长的比值这个指标能直接反映球房的最大营收上限在哪里。时段热力分析则能看出某个球台在工作日晚上八点到十点被高频预定那么运营人员可以在这个时段动态上调价格实现收益最大化。3. 软件架构设计与部署实操3.1 架构分层与各层职责软件架构图在我看来是开发者沟通的第一工具。整个系统我分了四层设备接入层、业务服务层、数据存储层和前端应用层。设备接入层跑的是MQTT Broker服务使用EMQX开源版作为承载。EMQX对海量设备连接的支持很成熟也支持设备上下线事件的Webhook推送方便业务侧实时感知设备状态。设备端通过TLS加密连接MQTT主题按球房ID/球桌ID/action的规则设计避免串台。业务服务层用Java SpringBoot搭建了五个核心微服务用户服务、订单服务、设备服务、计费服务、营销服务。微服务之间通过API网关统一路由服务内部通过消息队列解耦。比如用户下单后订单服务发出一条订单已创建的消息设备服务接收后下发开台指令计费服务接收后启动一个计费任务。这套异步设计保证了即使某一服务短暂抖动也不会影响其他模块运转。数据存储层使用了MySQL加Redis的组合。MySQL存储订单流水、用户账号、球房信息等核心数据Redis负责热点数据缓存球桌在线状态、实时计费中间值、用户登录态。另外还有一套ELK日志系统所有服务日志和设备心跳日志都汇聚进去排障时直接按设备ID或订单号搜索日志效率很高。前端应用层除了用户小程序还有Web版管理后台和商家App。Web后台使用Vue3加Element Plus开发商家App则基于uni-app打包既支持iOS也支持Android。3.2 设备端断网容错与本地缓存无人自助场景最怕的就是断网。用户正打着球网络断了如果不能继续开灯计时那是灾难性的体验。所以设备端的断网容错我做得很重。控制器固件里写了本地状态机离线前会记录当前订单号和开台时间。断网后设备继续维持灯光通电和门锁开启状态同时本地还在记录时间轴。恢复网络后控制器先重新连接MQTT再主动上报离线时间段内的状态变化和累计时长云端收到后补算计费。这里要特别强调离线期间的闸门逻辑如果用户在离线期间直接关灯走人没有在线上点击结账云端是不知道的。处理方式是设备在离线状态下依然监听人体传感器或门磁信号检测到用户离开后自动断开灯光并记录关灯时间恢复联网后一并上报。这样即使订单没有正常结束系统也能判定为设备侧已关灯订单可强制完结避免用户钻空子长期占用球台。3.3 部署形态与运维要点我先说一个明确的观点如果你的球房数量少于10家完全不需要一上来就上Kubernetes一台4核8G的云服务器加一台高性能MySQL实例完全够用。我做第一版部署时使用了单机Docker Compose编排三个核心容器EMQX、后端服务、MySQL Redis再加一台Nginx做反向代理整体成本很低一个月云资源费用不到300元。当球房数量超过20家、设备超过200台后才需要考虑服务横向扩容和消息队列分区。我的建议是先把EMQX单独拆出去跑一台机器然后后端服务无状态化前面加负载均衡数据库上只读副本这样能扛住一万台设备同时在线。运维上必须配置好三套告警设备离线告警、订单异常告警、计费服务Echo异常告警。这三套告警通过企业微信群机器人推送值班人员看到后可以在手机上直接处理。我实际运营前三个月告警推送量很大大部分是弱网抖动后来在固件里增加了心跳重连退避策略告警噪音减少了七成。4. 常见问题与排障实录4.1 开锁失败与卡单排查开锁失败是上线初期最大的客诉来源主要集中在三块继电器烧毁、Wi-Fi信号弱、云端状态与本地状态不一致。继电器烧毁多数是因为用了劣质模块电流余量不足。建议采购时必须选5V/10A以上的工业级继电器模组并且加装续流二极管保护。Wi-Fi信号弱这个问题更隐蔽很多球房的无线路由在包间死角位置覆盖很差。我的建议是球房部署时做一次Wi-Fi信号勘测每个球桌位置用手机测一下信号强度信号低于-70dBm的球桌必须加装AP面板或Mesh子路由不要抱侥幸心理。云端状态与本地状态不一致的问题我专门加了一个状态对账定时任务。每30分钟对全量订单和设备的本地状态做一次比对发现不一致时自动触发一次同步修正。比如用户在开台状态下被老板手动重启了控制器控制器本地的状态是空闲但云端还挂着进行中订单对账任务会优先按设备实际状态为准修正订单同时推送告警提醒老板处理。4.2 计费争议与数据一致性计费争议几乎无法完全避免但一定要把谁能查到原始证据这个问题解决好。我在数据层保留了每一次计费动作的原始记录包括时间戳、设备心跳时间、实际扣费金额、计算规则版本。用户申诉时运营人员可以直接拉出完整的时间线几点开台、几点续费、几点结算每一分钟的费用是怎么算出来的全部可追溯。实际遇到过一种情况很典型用户开台后手机没有锁屏离开球房时忘记结算车辆开出停车场后才想起订单还在计时最终账单金额远超预期。这种单子从规则上讲没错但用户感知很差。后来我在运营策略上做了优化当订单时长超过3小时且用户仍在线小程序端会推送请确认是否仍在球场的弹窗提醒如果用户5分钟内不做操作则自动推送一条续费待确认订单。这个机制显著降低了长尾争议订单的数量。4.3 软件著作权与合规上线很多做SaaS的团队容易忽略软件著作权证书不只是申请高新技术企业的加分项更是上架各应用市场、对接支付渠道、参与招投标的硬门槛。我这次项目上线前就把软件著作权申请材料准备好了包括源程序前30页和后30页、软件说明书和申请表。需要注意提交的源程序每页必须50行以上页眉标明软件名称和版本号说明书里要有软件架构图、核心功能说明和操作流程说明。支付渠道合规方面小程序内有充值和购买商品两个动作必须申请微信支付商户号并完成小程序支付功能的类目审核。台球行业属于休闲娱乐类目一般不会遇到特别严苛的资质卡点但营业执照经营范围一定要包含体育场馆服务或健身休闲活动否则个别地区会驳回支付申请。这一点在项目启动前就要和财务确认好不要等到上线前才去补资质。关于支付分、信用免押这类能力也需要在小程序后台开通对应的接口权限。开通后要注意用户协议和隐私保护指引必须明确列出平台将收集您的支付分信息用于信用评估审核人员会重点检查隐私政策是否完整。我一开始没在意这段文字结果小程序的版本审核被驳回了两次都是因为隐私政策里没有单独说明支付分和位置信息的使用用途。合同和分账体系也要提前设计。共享无人自助台球如果涉及加盟商和平台分账建议直接使用微信支付的分账能力让平台作为服务商商户作为特约商户交易后通过分账接口把约定比例金额分配给平台方。这种模式比商户提现后再手工转账合规得多也方便后续财务审计。写在最后这个软件从第一行代码到第一家球房上线前后花了大约四个月。回头看我最大的体会是做无人自助类项目技术难的不是某个点而是把硬件、软件、支付、运营、售后串成一条完整的服务链路。任何一个环节掉链子落到用户身上的体验都会打折扣。如果你也在做类似的项目我建议你先从最小闭环开始跑一个球房、两张台子、一台控制器、一个小程序把全流程跑通之后再谈规模化和功能扩展。忌一开始就追求大而全系统上线第一天就背上一堆复杂配置文件后续排障会非常痛苦。最后分享一个小技巧所有对外暴露的API接口从一开始就统一设计好错误码规范开发阶段多花点心思后面处理线上问题会节省你大量时间。