I upgraded to gateway 9 on a pi 3. The gateway app is working fine and weathermote nodes are working, but I get ACK:NOK from switchmote.
I downloaded new sketches from the guide for mightyhat and switchmote to no avail.
I implemented a new switchmote with the same behavior.
I loaded node and randomnumber sketches to the old switchmote moteino which was working fine before the gateway upgrade and sendwithretry prints nothing...
So this is one old and one brand new moteino 915Mhz WC doing the same thing.
Everything on switchmote functions except communication to and from the gateway.
Any suggestions on how I can troubleshoot further?
I have verified a moteino USB for which I haven't relaoded the sketch in a long time and it is functioning fine on the upgraded gateway.
So my weathermotes and moteino USB work, but not the new switchmote or the old switchmote which was working prior to the gateway upgrade.
One thing to note is the OLD P2 and NEW P3 SwitchMotes have different sketches.
Their EEPROM settings did not change, so all you should do is make sure your P3 has the P3 sketch. See this guide page (https://lowpowerlab.com/guide/switchmote/programming/) for the P3 sketch link.
The older P2 - if untouched - and based on the fact you report other motes are working (same settings and everything matches) - should also work.
Did you happen to take a backup before the V9 upgrade?
I tried the switchmote sketch in your link. No change.
I sill have the old gateway Raspberry PI untouched as a backup.
It seems no new moteino will talk to the gateway. Only the ones where no new sketch was loaded.
I tried with yet another spare moteino with the same results.
I've checked gateway serial communications and all is fine.
I loaded the MIGHTYHAT gateway sketch from the MightyHAT guide. I have R3. DO I need a new MightyHat?
How can I further troubleshoot? in minicom I see the weathermotes sending data back to the gateway.
I've made a little progress. I loaded an old weathermote sketch to one of the moteinos that was failing and it worked.
So I have a mismatch of sketch to gateway sketch I'm guessing. Any suggestions on what switchmote sketch I might want to load?
Look in the switchMote github directory: https://github.com/LowPowerLab/RFM69/tree/master/Examples/SwitchMote
R2 is for the older R2.
The SwitchMote.ino is for R3.
and what gateway sketch should I use for gateway v 9 on a mightyhat R3?
I pulled the switchmote sketch and the hightyhat sketch from github RFM69/examples and the results are the same. Previous moteinos are working and the new switchmote is not.
Next I'm going to pull all the libraries new from github and recompile and reload everything.
MightyHat sketch is the same. Nothing changed as far as firmware. Only the gateway software has changes. And for your p3 switchmote you need yhe proper sketch. And of course match all settings in the Gateway as before (or just keep your old settings file).
I'm out of ideas. I've reloaded the gateway (mightyhat) and switchmote p3 sketches after replacing all the libraries with the latest versions from github.
When I load a weathermote script on my original switchmote moteino, it pops right up on the gateway as a new node. When I load a switchmote sketch or the randomnumber sketch onto the same moteino or the new switchmote, give the switchmote a never used node ID and do a reboot on the switchmote, and reset the switchmote, no new node pops up. If I manually add a new light switch node and click one of the buttons, the gateway reports ACK:NOK.
Would you say I am not talking over radio between the moteino and the gateway?
I manually entered the settings on the gateway v9, but nothing changed besides the IP of the gateway.
Any suggestions would be welcome.
Found the problem with randomnumber sketch. I did not comment out HW.
Still don't know how to debug switchmote. I've gone over the EEPROM config settings and it looks right.
Would like to be able to debug the radio initialization and sendwithretry calls, but don;t know how.
loseymark,
After loading the sketch, did you push any buttons? It won't just pop up on the gateway unless you do.
yes, I activated all the buttons plus reset
I'm guessing it's an assembly issue. My soldering skills and equipment leave a lot to be desired, and that's being generous.
So I purchased two switchmotes R3. I assembled the second one being very careful. It went together well. Tested the PCB. Pretested the moteino with the remotenumber sketch. All looked good. Loaded the sketch. Saved, rebooted, hooked to the MAINs. Same behavior as before. Activated all buttons plus the reset. The relays, switches, LEDs work. activating the buttons on the switchmote does not send any data to the gateway.
Manually added the node with httpendpoint. When a button is pressed on the node page, I get "GTWCMD:52:BTN1:1 ACK:NOK"
The only thing I can do now is to try the old gateway.
Still looking for a way to validate radio initialization and sendwithretry. Should this happen upon switchmote button press? If not, when?
What exactly is Remotenumber sketch?
Anyway sounds like the SwitchMote is loaded with the right sketch (or else the LEDs would be out of order if you used an older sketch on R3).
You do not need to change ANYTHING in the SwitchMote sketch, for it to work.
You indicated that you configured that/those R3 SwitchMotes via Putty as described on this page (https://lowpowerlab.com/guide/switchmote/programming/). The settings absolutely have to match your Gateway settings. ID needs to be unique. The HW/HCW setting is crucial. Once restarted and settings are permanent, that SwitchMote is ready to talk to your Gateway, which also needs the correct PiGateway sketch (https://github.com/LowPowerLab/RFM69/blob/master/Examples/PiGateway/PiGateway.ino) - and matching settings (this time in the sketch itself).
I thought you also indicated that other motes are transmitting data to your Gateway, so the only questionable one was the new SwitchMote.
This, like 99.9% of the world's engineering problems, warrants a divide-et-impera approach. Isolate what works, and break down what doesn't, then chew at the bits that don't work.
Maybe this makes you feel better ... A few days ago I had a family friend over to hook him up with a Switchmote and a Gateway so he could automate his lights, soldered the SM and walked him through everything and guess what - it took me several tries to get everything right, from the gateway settings, to getting the right sketch, the right bauds for putty, etc etc. I must have looked like a noob sitting there wondering why the SM doesn't show up. And you'd think I'm the creator of all this ... yeah :-X
OK, I went through everything again and found the gateway sketch did not have high power commented out SHEESH.
I took out all my debug changes and it is working fine except for one thing.
httpendpoint does not activate the relays or the button state on the switchmote. Should it? I'll look into the code to see if I can figure something out, but if you know for sure whether it should or shouldn't, please let me know.
I'm hoping it does, because this will let me integrate switchmote with other voice activation work I have done.
Quote from: loseymark on July 30, 2019, 08:15:11 PM
OK, I went through everything again and found the gateway sketch did not have high power commented out SHEESH.
SHEESH indeed ;D
We will make this overlook the HopeRF grand prize of confusion :)
But don't feel bad, it happens more often than you think ;)
The SwitchMote does NOT work with HTTPENDPOINT at all. You simply remove that node and recreate it by pressing the buttons on the switchMote, then picking the SwitchMote (ie "Light Switch") type from the node TYPE dropdown.
I added logic to call sendMessageToNode in the httpEndPoint function if this is an existing node switchmote and the metric regexp includes 'btn'. It activates the relay and button on the switchmote and correctly updates the node on the gateway.
Ok, but I'm at a loss as to how httpEndPoint has anything to do with a radio based SwitchMote.
With my logic addition to function httpEndPointHandler(req, res), if I issue https://xxx.xxx.x.xxx/httpendpoint/?id=54&btn1=1 for an existing node and the node type is SwitchMote and the queryStringKey includes 'btn' like so:
// after ....
var tokenMatch = metricsDef.metrics[metric].regexp.exec(queryStringKey+':'+queryString[queryStringKey]);
// my code --------------------
if (existingNode.type == 'SwitchMote' && queryStringKey.includes('btn')) smCommands[smCommands.length] = [id, tokenMatch[0]];
//-------------------------------
then I build an array from id and tokenMatch to call sendMessageToNode like so:
// for switchmote only, send the httpendpoint message to to the node to activate relays and buttons
smCommands.forEach(function(element) {
sendMessageToNode({nodeId:element[0], action:element[1]});
});
and it sends a GTWCMD via radio to the SwitchMote activating the switchMote button(s). I'm not sure how I'm confusing you, but I hope this explains it.
I have this integrated with other voice commands through Google Voice Kit. It's awesome. I really like the on/off at sunset/sunrise too. This is a great feature. I also have other RF Outlets under control and with httpEndPoint calls I can keep the gateway updated after I send RF commands from Raspberry Pi to RFOutlets. I used to do this with a MoteinoUSB for multiple nodes sending serial data to a Moteino which passed it on to MightyHat and updated the gateway. A real hack, but I replaced all that with simple httpendpoint commands. By defining my RF Outlets as virtual nodes, I can also control them with a button control on the gateway. I inserted logic in controlClick to call a python script that sends RF codes to the outlets.
httpEndPoint is just what I needed, thanks.
Oh ok, I see now, so you're just using the HTTPENDPOINT to activate the SwitchMote. Sure, that's very possible.
I think I confused myself - I recalled you said you added the SwitchMote with the "Add Node" button because you were having trouble with it showing up, so once it worked I thought why would you want to use HTTPENDPOINT to operate it since it's a radio mote.
But I get it now, glad that my new HTTP feature found a useful (and interesting) use case for someone!
And yes I love the SMs turning on/off by themselves every day according to sunrise/sunset.
Quote from: Felix on August 02, 2019, 09:48:17 AM
I love the SMs turning on/off by themselves every day according to sunrise/sunset.
Still waiting for one to be able to use sunrise/sunset for both relays on the same SwitchMote.. :P
I wonder if that could be easily implemented by adding an event like switchMoteBothON_PM and switchMoteBothOFF_AM
and then add sendMessageToNode for the additional button like below, then assign the events to the switchmotes desired.
switchMoteBothON_PM : { label:'SwitchMote ON at sunset!', icon:'clock', descr:'Turn this switch ON at sunset', nextSchedule:function(node) { return exports.millisToFutureDate(exports.nextSunriseOrSunset(0), exports.ONEDAY*2); }, scheduledExecute:function(node) { sendMessageToNode({nodeId:node._id, action:'BTN1:1'}); sendMessageToNode({nodeId:node._id, action:'BTN0:1'}); } },
switchMoteBothOFF_AM : { label:'SwitchMote OFF at sunrise!', icon:'clock', descr:'Turn this switch OFF at sunrise', nextSchedule:function(node) { return exports.millisToFutureDate(exports.nextSunriseOrSunset(1), exports.ONEDAY*2); }, scheduledExecute:function(node) { sendMessageToNode({nodeId:node._id, action:'BTN1:0'}); sendMessageToNode({nodeId:node._id, action:'BTN0:0'});} },
Yes you can add a new event in your user folder, based on the current one, to switch ON another button.
Or copy+modify the existing one to include 2 commands (rather than 2 separate packets).
I want to remind folks that read this:
The given example events functionality are templates for you to customize and come up with interesting new behavior. While this software is free for personal non-profit use, you are encouraged to try code new things on your own - I do not have the time to code everyone's personal requests.
However interesting requests that would benefit most users might be given priority to be implemented in a future release.
@loseymark
Thank you for the response. Much appreciated
edit: I tried the events you posted but no luck, only BTN1 turned on.
[08-07-19_20:48:20.825] [LOG] **** RUNNING SCHEDULED EVENT - nodeId:5 event:switchMoteBothON_PM...
[08-07-19_20:48:20.831] [LOG] NODEACTION: {"nodeId":5,"action":"BTN1:1"}
[08-07-19_20:48:20.832] [LOG] NODEACTION: {"nodeId":5,"action":"BTN0:1"}
[08-07-19_20:48:20.834] [LOG] **** SCHEDULING EVENT - nodeId:5 event:switchMoteBothON_PM to run in ~23h58m
[08-07-19_20:48:20.851] [LOG] [5] DB-Updates:1
[08-07-19_20:48:20.890] [LOG] >: ACK:OK
[08-07-19_20:48:21.013] [LOG] >: ACK:NOK
[08-07-19_20:48:22.038] [LOG] >: [5] BTN1:1NULmptyString [RSSI:-71][ACK-sent]
[08-07-19_20:48:22.041] [LOG] post: /home/pi/gateway/data/db/0005_B1.bin[1565225302,1]
[08-07-19_20:48:22.043] [LOG] post: /home/pi/gateway/data/db/0005_RSSI.bin[1565225302,-71]
[08-07-19_20:48:22.052] [LOG] [5] DB-Updates:1
@Felix
I did try adding an event as you stated and when it didn't work I posted about it and even included a video showing you it didn't work.
I don't expect you to take a lot of time out of your busy day to figure this out when nobody else would benefit but it just amazes me that nobody has ever ran into a situation where they needed to control both relays on a single SwithMote at the same time. Maybe I should have only purchased the single relay model.
https://lowpowerlab.com/forum/pi-gateway/switchmote-btn0-btn1-on-at-the-same-time/msg21417/#msg21417 (https://lowpowerlab.com/forum/pi-gateway/switchmote-btn0-btn1-on-at-the-same-time/msg21417/#msg21417)
maybe a delay is needed between the two sendMessageToNode executions
@Sparky
You should check your switchmote sketch and determine if debugging is enabled. Make sure the following line in the sketch is commented out:
#define SERIAL_EN //comment this out when deploying to an installed SM to save a few KB of sketch size
@loseymark
Thanks
@ssmall
Here is the sketch I'm currently using with no changes. Thanks for the response
https://github.com/LowPowerLab/RFM69/blob/master/Examples/SwitchMote/SwitchMoteR2.ino (https://github.com/LowPowerLab/RFM69/blob/master/Examples/SwitchMote/SwitchMoteR2.ino)
It took a little research on how to pass values to setTimeout, but the event definitions below just worked for me. If you try to do back to back sendMessageToNode calls, the second one will fail (moteino/radio busy?). This approach uses setTimeout to schedule action BTN0:1 and BTN0:0 one second after the sendMessageToNode for BTN1. Kind of a hack, but it worked.
switchMoteBothON_PM : { label:'SwitchMote both ON at sunset!', icon:'clock', descr:'Turn both switches ON at sunset', nextSchedule:function(node) { return exports.millisToFutureDate(exports.nextSunriseOrSunset(0), exports.ONEDAY*2); }, scheduledExecute:function(node) { var nID = node._id; setTimeout(function() { sendMessageToNode({nodeId:nID, action:'BTN0:1'}); },1000, nID); sendMessageToNode({nodeId:node._id, action:'BTN1:1'}); } },
switchMoteBothOFF_AM : { label:'SwitchMote both OFF at sunrise!', icon:'clock', descr:'Turn both switches OFF at sunrise', nextSchedule:function(node) { return exports.millisToFutureDate(exports.nextSunriseOrSunset(1), exports.ONEDAY*2); }, scheduledExecute:function(node) {var nID = node._id; setTimeout(function() { sendMessageToNode({nodeId:nID, action:'BTN0:0'}); },1000, nID); sendMessageToNode({nodeId:node._id, action:'BTN1:0'}); } },
Thats great you got it to work! Some things going on in the family recently and have not had much time but I will definitely try it out.
Thanks for your time! :)
edit;
Well it don't like me I guess.. only B0 came on.
[08-13-19_14:35:57.857] [LOG] **** RUNNING SCHEDULED EVENT - nodeId:5 event:switchMoteBothON_PM...
[08-13-19_14:35:57.862] [LOG] NODEACTION: {"nodeId":5,"action":"BTN1:1"}
[08-13-19_14:35:57.864] [LOG] **** SCHEDULING EVENT - nodeId:5 event:switchMoteBothON_PM to run in ~23h59m
[08-13-19_14:35:57.878] [LOG] [5] DB-Updates:1
[08-13-19_14:35:57.901] [LOG] >: ACK:OK
[08-13-19_14:35:58.862] [LOG] NODEACTION: {"nodeId":5,"action":"BTN0:1"}
[08-13-19_14:35:58.909] [LOG] >: ACK:OK
[08-13-19_14:35:59.933] [LOG] >: [5] BTN0:1 mptyString [RSSI:-59][ACK-sent]
[08-13-19_14:35:59.937] [LOG] post: /home/pi/gateway/data/db/0005_RSSI.bin[1565721359,-59]
[08-13-19_14:35:59.947] [LOG] [5] DB-Updates:1
edit;
I increased the delay to 3 seconds and now it appears to be working. Thanks again loseymark!
That's great. One potential problem might be with multiple switchmotes all doing sendMessageToNode at the same time. I have two and it seemed to work OK.
I'm using httpendpoint for some RF Outlets and am having trouble with collisions, but I think it may be in the codesend code, not the gateway. I resolve it with delays in between the codesend calls.