Kbrooking

If you haven't found my github yet https://github.com/NickWaterton/mcScript I have examples of exactly that, plus a python program (beacon_decode.py) for receiving the beacons and converting them back to regular mqtt messages.

I currently support 12 data types (I think), such as temperature, battery, Rssi, humidity, pressure, altitude, boolean etc.

The data is converted to 24 bits, so there are limits on the range of numbers that can be sent, and you are limited to 2 decimal places, but the range is +/-32k, so enough for environmental sensors.

Does anyone know how time zones work? And how does the RTC on modules get updated? Is there a way to force an update?

I've been playing with my Time library, and find that quit often modules do not get their RTC updated, and so report 1999 or 2000. I assume the gateway is getting the time via NTP, and sends it to the modules. Is this just on boot, or does it periodically update? Can you get a module to request an update?

There is a time zone setting on the gateway config setup. How does this work? I have tried entering various values -4:00 for instance, but I don't know how this is passed to the modules, on boot? Plus it seems to make random changes to the module time (unrelated to the actual number). For instance entering -4:00 made 10 hours difference to the time, 0 made -4 hours difference to the time.

Z time is 1 hour off (DST I assume), so -4 hours should be eastern, but no, it's 10 hours off. Bit confusing how this works.

Anyone know?

Is there a maximum length of a string?

I ask, because I have a json object, which I am publishing via MQTT, and I'm getting a run time error "arguments too long", which is where I convert the json to a string (prior to ListofByte).

Depending on how long the strings in the json are, I get the error, or not. The magic number seems to be around 280 characters.

I'm working around it by splitting the strings into two json objects, and publishing both of them (which works).

What are the limitations?

Thanks,

Update:

Checkout my github https://github.com/NickWaterton/mcScript for a new Demo 205 test program!

This program publishes the GPS location on motion start, or end of motion (selectable). Currently publishing via MQTT as we don't have a SigFox network in Canada, but good for proof of concept.

Also new: updated LIS2DH12 (accelerometer) library, with easy to configure options, and capability of reading the event name that triggered an interrupt (double_click, x_axis etc) (see demo 205 program for usage, and source for details).

Updated MQTT library (only one change as mcStudio 906 didn't like checking the count of Nothing) minor, but needed, still backwards compatible.

New mcthings_log.py Python program for logging (and displaying) MQTT data from your modules (actually should work with any mqtt data), features pretty printing of json, decoding of timestamps (at least my implementation of them), calculation of transmission delay, etc. Command line configurable, probably full of bugs, but works for me.

NOTE: mcStudio 906 and the demo 205 have some serious gremlins in them. The following is the only way I have been able to load a program into my 205:

• Start mcStudio (this usually takes two tries), and load project. Do not connect 205 yet!
• Click on build (hammer, icon). This will fail don't worry! This is just a test from the demons of debugging hell
• Click on build again (wait.. wait) success! Demons begone. MCThings people you owe me 4 hours of my life back for figuring this out
• Remove tiny power jumper from 205, and try not to loose it again...
• Connect 205 via USB (I have never had OTA update working, so go with this)
• Open "devices" screen, and connect "testboardGateway"
• Insert tiny power jumper in USB position (assuming you haven't lost it again)
• Wait for device to appear, and click on connect
• Back on the main screen, click on "download to device" (or upload if you think that way), anyway, send program to 205. Do not try run, to debug, mcStudio will crash!
• Wait for success message box, click OK. Then disconnect USB (device will not publish when connected to USB, so you can't see any messages)
• Move tiny power jumper to battery position, and watch mqtt/logging program for data. Shake 205 to activate GPS, gasp as data appears (OK there is some waiting, a lot of waiting)

If you want to change anything, you can't reconnect the 205 (go ahead and try, mcStudio will crash when you click on "connect"). You have to make your changes, save them, then close mcStudio, and start from step 1 above. If you think this takes a long time to write/debug a program this way, you would be right.

If anyone has found a faster/easier way to do this, please let me know and I will be eternally grateful.

I am certain that there are some bugs in my test program, but the debug cycle was so exhausting, when it was working reasonably well, I decided to release it into the wild.

Things to note!

The push buttons do not work the way the way you think (at least if you are a positive logic person like me), they work on negative inside out logic. To be fair the clues are in the documentation, but the example is bonzo (if that is a word). The logic is active low (clue!), so false is button pressed. The example actually works because it ignores the button press interrupt, and detects the button release interrupt (SW1 = true = not pressed). So if you think the example detects button presses, it doesn't, it detects button unpresses by testing to see if the SW1/2 variable is unchanged from the normal state (true). As I say bonzo to me until you figure it out (but it is important if you want to detect long vs short presses).

Devices (all of them) do not publish when connected to USB testboard gateway. As you don't seem to be able to disconnect the gateway once it's connected. You will see nothing published after loading the program.

You can't debug a program with an MQTT.Subscription in it (also any type of module)

If you have a run time error in your program, Led 2 will flash every 5 seconds or so as the modules reboots. If you are using LED 2 to indicate activity, this may confuse you for some time.

It is really hard to tell which LED is flashing as they are all red, and right next to each other. Obviously given the cost of different coloured LEDs, this is understandable, so you have to look really closely to see what is being indicated. Or just turn an LED on and leave it on to make things easier.

With the current scarcity of switches, a tiny jumper was needed to select USB or battery power. I suggest attaching it with a large chain, to prevent loosing it.

Try it out!, let me know what you think, and feel free to improve it.

All I need now is a SigFox network, and a gateway that doesn't loose WiFi at crucial moments.

And yes, the wife is away visiting family this weekend.

Update,

I can now confirm that all modules and all data types published by MQTT suffer from random delays of up to several minutes (not just json).

Sometimes they arrive immediately, sometimes delayed by seconds to minutes. Beacons always arrive immediately.

Please take a look at this, I have posed my code to github https://github.com/NickWaterton/mcScript The two projects that show this problem the easiest are DoorSensor (the 110 module version) and BatteryMonitor.

Please let me know I'm not living in a time warp...

The

Thread.Sleep(10000)
Thread.ClearHardwareEvent()

In inSync() won't do anything (except for a small delay), so you should remove that.

The second occurance in ReedSwitchChanged() should come first, ie before if ReedSwitch = True Then....

What this is doing is compensating for switch bounce. Because the reedswitch is a physical piece of metal, it can "bounce" so you get several interrupts while it is "bouncing". If you read the ReedSwitch while it is bouncing, you can get false readings. The idea behind Thread.sleep(10000) is to wait 10ms for it to stop bouncing, then read it, hence the delay has to come before you read the switch.

The Thread.ClearHardwareEvent() clears any waiting interrupts in the routine that called it, in this case probably caused by the switch bouncing (otherwise the interrupt may trigger twice - the queue is only 2 deep).

This means that you can't read events that happen faster than every 10ms, but given that this is a physical switch, that is probably not possible anyway.

Hope this explains!

Is that correct? A shared event can't call a public function in the same class? I swear I'm doing this, and it works.

I'm not debugging though, I can't get debugging to work if I have an mqtt subscription in the code.

Would the code not work if you did this, or would it cause obscure bugs?