Where's the Wizard ?

Buzby

Senior Member
Prompted by the current thread about web-enabled ESP things, I revisited the PICAXE Net Server. ( https://www.picaxestore.com/net002 ). I have a couple of these, bought as scrap for £1.20 each, and both work fine, but I've not done anything with them.

It was something relating to TC/PIP networks and PIC micros that first introduced me to PICAXE many years ago. The company I worked for had a project that needed TC/PIP on a PIC, and somehow Rev-Ed got involved. Clive helped me a lot, and gave me a few PICAXE chips to play with. That was my start with PICAXE. ( The project itself was a total failure, but not because of PICAXE, there were other forces at play. )

Move on to today, and the proliferation of tiny 'network savvy' micros, makes me wonder if Rev-Ed have missed a trick.

The PNS was an early incarnation of what the ESP-type thingies are today. ( I've got a couple of ESP-thingies, each with a tiny OLED screen and WiFi, progammable like an A*****, over the air. These things cost me pennies. )

But it seems like the web-enabled PICAXE is not just dead, it's been buried as well. ( What happened to the NetServer Wizard that was in PE4.1.16 and later ? )

I'd really like to see something like the AXE201, but with added WiFi. It's things like this that kids are cutting their teeth on nowadays.

Well, thats my rant over,

Cheers,

Buzby
 

hippy

Senior Member
But it seems like the web-enabled PICAXE is not just dead, it's been buried as well. ( What happened to the NetServer Wizard that was in PE4.1.16 and later ? )
With the PNS product no longer available, and a long time gone, it doesn't really make sense to include the software support for that within PE6. I believe the PNS Wizard was an integral part of PE5 so you would have to use that to develop for the PNS product.

I recall that the main part of PNS configuration was building up an Eeprom image and flashing that to the PNS and I remember building such images outside PE5 so a standalone Wizard which could be incorporated in PE6 could be created but, given that was so long ago, I don't remember what I did, where that code would be, or what it entails.

For the few cases where PNS is being used the easiest course is to use PE5.

I'd really like to see something like the AXE201, but with added WiFi. It's things like this that kids are cutting their teeth on nowadays.
The PNS product was basically a separate PICmicro chip programmed with a TCP/IP stack which allowed interfacing to PICAXE chip. The modern approach would be to replicate that using an ESP or similar to provide a bridge to the PICAXE.

Using an ESP as a smart peripheral for a PICAXE, or a PICAXE as a smart peripheral to an ESP, should be possible but there probably wouldn't be an immediate business case for bringing the two together on a single PICAXE board.

Any prototyping of such a product would start with a PICAXE plus ESP so that's he best way to go whether it became an integrated product or not.

The hard part is defining just what "PICAXE with WiFi" is or does, how people would imagine using it. It should be easy enough to have an ESP act as a PNS, have it as a web server with a web site held in Flash or I2C Eeprom, have it pass commands to a PICAXE, read data from a PICAXE and return that within a web page, but I am not sure how useful just that is. I've let things like AJAX and REST pass me by which may be the key to making things work.

I do have a number of ESP8286 and ESP32 devices but haven't done anything much with them. I am guessing there are some web server reference designs out there so I guess I should take a closer look at how they work and what they can do.
 

Buzby

Senior Member
... start with a PICAXE plus ESP so that's he best way to go ...
The ESP boards are way more powerful than a PICAXE, so the PICAXE would be virtually redundant in this case. I was think more along the lines of combining the PICAXE with a simple WiFi-UART, like this one I Googled just now : https://mikroelectron.com/Product/UART-TTL-WIFI-MODULE/

In this case the WiFi heavy stuff is provided by the chip, and the PICAXE has all the goodies we know, like easy coding and built-in peripheral controls.

... a web server with a web site held in Flash or I2C Eeprom, have it pass commands to a PICAXE, read data from a PICAXE and return that within a web page, but I am not sure how useful just that is.
This is exactly what the current IOT stuff is on about, connecting little things to the Internet. The chip doesn't need to serve a webpage, it just needs to send and receive internet packets. Services like Thingspeak do all the presentation.

Anyway, I'm too busy to even finish my PICAXE projects, so my drawer full of ESP, RPi, LoRa, GSM, etc. bits is staying shut !.

Cheers,

Buzby
 

geezer88

Senior Member
I'm with Buzby on this. I'd love to have an app on my smart phone or tablet that I could customize to do stuff with a picaxe system connected by bluetooth or wifi. It would be really neat to instantly see on my phone the status of gates and sensors, or control actuators or other variables. It seems to me that this would be an excellent way to teach kids how the "connected" stuff works.

I know there are bits and pieces out there already to do these things, but Rev Ed could do it better/easier with a complete IoT solution that "just works".

tom
 

Buzby

Senior Member
... I'd love to have an app on my smart phone or tablet that I could customize to do stuff with a picaxe system connected by bluetooth or wifi. ... Rev Ed could do it better/easier with a complete IoT solution that "just works".
Hi Tom,

Yes, I've been down that route. A 28X2, HC-04 Bluetooth module, and Basic4Android to write the app. ( This was for a very complex app. )

For the sort of basic IO control and monitoring that you want, take a look at RoboRemo. When I tried it I was very impressed, and now it does WiFi as well. ( I see now it also does USB serial, even simpler for testing your app without any wireless. )

So what you want is easily achievable with a PICAXE ( from Rev-Ed ), a Bluetooth module ( from China ), and RoboRemo ( from Victor ).

It would be even easier if the whole solution was in the PICAXE ecosystem.

We can live in hope.

Cheers,

Buzby
 

hippy

Senior Member
I was think more along the lines of combining the PICAXE with a simple WiFi-UART, like this one I Googled just now : https://mikroelectron.com/Product/UART-TTL-WIFI-MODULE/
There does seem to be previous PICAXE projects using similar but I have had no experience in using them -

https://picaxeforum.co.uk/threads/picaxe-to-net-with-wifi-to-serial-module-tlg10ua03.24798

The chip doesn't need to serve a webpage, it just needs to send and receive internet packets.
But what exactly are these "packets" ? There is usually a whole lot of additional protocol which needs to be added on top of raw data or commands, and then stripped off, to get something from A-to-B.

So what you want is easily achievable with a PICAXE ( from Rev-Ed ), a Bluetooth module ( from China ), and RoboRemo ( from Victor ).

It would be even easier if the whole solution was in the PICAXE ecosystem.
If it can be done then it would seem we already have a solution. It's not clear how making it a part of the PICAXE ecosystem would improve things or what that would actually mean or entail.

Perhaps it just needs someone more familiar than I am with IoT to document what to use and how to set things up, make it work ?
 

Buzby

Senior Member
But what exactly are these "packets" ? There is usually a whole lot of additional protocol which needs to be added on top of raw data or commands, and then stripped off, to get something from A-to-B.
This is where an integrated single-supplier solution makes huge sense.

This example from the ESP world shows a message being sent to thingspeak. : sendts(5C1J2FHRGQM44M7R,1,"HELLO WORLD FROM ESP")

The long string is the users ID, the 1 is the channel number, and the message is Hello World.

The clever part is the 'sendts' command. This is part of the ESP BASIC, just like HI2COUT is part of PICAXE BASIC. Both instructions need an earlier instruction to do their initial setup, but after that all the protocol handling is invisible to the user.

This method fits in well with the PICAXE way of doing things, and as the code and hardware would be all under Rev-Ed control there would be no problems with incompatible syntax. ( It was mentioned in the other thread about the AT GSM command minefield, and the thread you posted https://picaxeforum.co.uk/threads/picaxe-to-net-with-wifi-to-serial-module-tlg10ua03.24798 shows the problems when different 'identical' WiFi modules were obtained from different suppliers.)

The idea of a module like the AXE201, but using a more powerful PIC running a 28X2 core with WiFI or Bluetooth, and with language extentions built in, is very attractive.

One of the reasons for the development of PE6 was the ease with which new features could be added, and a set of IOT friendly features would be right in keeping with whats happening now. ( PE6 is eight years old, nobody knew what IOT was back then. )

Cheers,

Buzby
 
Last edited:

hippy

Senior Member
The idea of a module like the AXE201, but using a more powerful PIC running a 28X2 core with WiFI or Bluetooth, and with language extentions built in, is very attractive.
I am sure it is. But, it's quite a big ask.

Not only would the compilers and PE6 need updating, we would need to find a PICmicro with WiFi and/or Bluetooth on-board or decide upon a suitable module which connects to that.

Then port the PICAXE firmware to work on that PICmicro, plus add the firmware which implements the entire WiFi, Bluetooth, and TCP/IP stacks. We would effectively be replicating the ESP firmware and all the libraries which interface to ThingSpeak, other desired IoT services, and would need a generic mechanism to support IoT services which may come along in future..

And, on top of doing all that, debug it and ensure everything works.

That's not going to be easy nor quick to do, is a considerable amount of work and effort.

A more pragmatic solution is something which can bridge a standard PICAXE to another and the IoT clouds and provide easy to use mechanisms to do that.

A serial link to the bridge would be one way to do that and the bridging could be encapsulated in macro commands which would have those commands appear as if built into existing PICAXE chips. Bingo; that sendts("APIKEY",1,"HELLO FROM PICAXE") command is done and dusted.

The only thing one needs to think about is what IoT macros are needed, implement them and document them, describe how to use them. That in essence is 'PICAXE IoT' delivered.

That leaves the bridge. That could be a PC, Pi, or ESP with appropriate firmware. All those have the WiFi and TCP/IP stacks already implemented, meaning zero effort beyond writing the code which sits between the serial to the PICAXE and the stack.

That's fairly easy to do. Easy enough that in half a day I have two PICAXE, each lighting the other's LED when its button is pushed. Not without it's complications and there are some rough edges to iron out.

That's PICAXE to PC via serial, via ethernet to my router then over WiFi to a Pi, through another serial connection to a second PICAXE. The same bridging software written in Python runs on the PC and Pi, it would even send data to ThingSpeak if I had an account. I can also control each Pi from a phone's web browser and it would be easy enough to do so from an app.

So that's basically PICAXE IoT done, apart from those rough edges. I haven't implemented reading of data from a remote PICAXE yet, and haven't even considered Bluetooth.
 

lbenson

Senior Member
So that's basically PICAXE IoT done
And +that+ I have a lot of, mostly with little openWrt (linux deriviative) routers (NSLU2, wr703n, dockstar, GL.inets, nexx wt3020s, pogoplugs and various odds and ends) providing the wifi for the picaxe. These send temperature readings and allow me to turn on the electric heater in the barn from my phone, and allow me to control my pan and tilt rivercam, and turn on zones in my heating system. But it is a hodge-podge (and some were pretty pricey in their day). There's no little controller I like better than the picaxe, but other choices are eroding that sentiment because they have wifi built in.
 

hippy

Senior Member
But it is a hodge-podge
But it wouldn't be a hodge-podge if you had chosen just one product as a bridge, say an ESP, accepting that it wasn't available at the time. And it's probably how it is because there wasn't a single well-defined framework available to work within.

A PICAXE WiFi module is no different to a PICAXE plus ESP in my view, because that is almost certainly what a PICAXE WiFI module would be if it existed. Okay we don't have ESP bridge firmware but someone could create that.

That would be just like the AXE171 MP3 player; a PICAXE plus MP3 module because we don't have MP3 capability on a PICAXE. A modern day AXE210 Connect / XBee board.

All this currently works ... Flashing a LED on a remote PICAXE ...
Code:
#Include "iot.inc"
Target("192.168.0.130")
Do
  SetHigh(B.7)
  Pause 1000
  SetLow(B.7)
  Pause 1000
Loop
And the receiving side is just ...
Code:
#Include "iot.inc"
Do
Loop
Setting a remote LED to a local button ...
Code:
#Include "iot.inc"
Target("www.myhomepicaxe.co.uk")
Do
  SetLow(B.7)
  Do : Loop While pinC.3 = 0
  SetHigh(B.7)
  Do : Loop While pinC.3 = 1
Loop
Updating a ThingSpeak channel ...
Code:
#Include "iot.inc"
Do
  ReadTemp C.0, b0
  SendTs( "MyApiKey", 1, b0 )
  Pause 15000
Loop
I don't see how it could be more integrated than that seeing as it's how it would be if the PICAXE did have WiFi on-board, except one has to add the #INCLUDE..

I'm not sure what more anyone would want, why that wouldn't fulfil the need. I'm happy to be enlightened.
 

lbenson

Senior Member
But it wouldn't be a hodge-podge if you had chosen just one product as a bridge, say an ESP, accepting that it wasn't available at the time
Right. NSLU2s came and went; Dockstars came and went; WR703Ns are still around, but the GL.Inets offer the promise of I2C and I/Os (but nowhere near the flexibility of a PICAXE). I guess the ESP-01 is what we have now (but I remember it, from several years back, as being stubborn). Maybe the path has been smoothed, both as to flashing it if necessary, and controlling it with the AT command set.

I'm not sure what more anyone would want, why that wouldn't fulfil the need
Convenient ability to serve a web page and respond to it interactively.
 

Buzby

Senior Member
... That would be just like the AXE171 MP3 player; a PICAXE plus MP3 module because we don't have MP3 capability on a PICAXE.
Exactly !.

The AXE171 is all under the control of Rev-Ed. The MP3 device is not built by Rev-Ed, but it is tried and tested by Rev-Ed, the PCB is designed by Rev-Ed, the PICAXE is Rev-Ed, and a known working code is provided by Rev-Ed.

If an AXE171 user has a problem with is device he just asks Rev-Ed for help. ( Well, the forum more likely. )

All the pitfalls and jumping through hoops to get a 3rd party MP3 module wired up and running have been taken care of. For the user, It Just Works !.

Now look at the ESP mess. Have you got the right firmware ?. Does the AT command set match ?. Is it wired to the right pins ?.

A Rev-Ed board, with a 28X2, some supplied #macros, and a WiFi-UART, is no different to a an AXE171, and PE6 would have a wizard for it.

Now I know Rev-Ed would never sell these new boards at 5 for $10, but users will pay for something they know will work straight out of the box, and has real support if needed.

Cheers,

Buzby
 

hippy

Senior Member
Convenient ability to serve a web page and respond to it interactively.
But ...
The chip doesn't need to serve a webpage, it just needs to send and receive internet packets.
This is where the main difficulty lies; nailing down exactly what IoT means, what Wireless Connectivity means.

Getting a web page out the PICAXE was pretty easy. Sending 'actions' wouldn't be much more difficult; one of those loose ends I need to tidy up.
Code:
#Define HasWebPage
#Include "iot.inc"
Do
Loop

WebPage:
  SerTxd("Counter = ", #w1 )
  w1 = w1 + 1
  Return
The bridge adds <html><head>...</head><body>...</body></html> decoration so the PICAXE doesn't have to.
 

lbenson

Senior Member
The bridge adds <html><head>...</head><body>...</body></html> decoration so the PICAXE doesn't have to.
Now you have to program 2 devices. Been there, tired of it.

I'll readily admit that serving a web page is different from sending a sensor reading or responding to a command.
 

hippy

Senior Member
Now you have to program 2 devices. Been there, tired of it
That's not really overly onerous given it's a one-time programming and one would have to program that device anyway if not using a PICAXE.

If parts were available pre-programmed there would be nothing to do, and even if not, knowing which device to use, which firmware to burn into it, would make that easy as it could be.

It might even be possible to create a programming wizard which identified the device, the appropriate firmware to use, and did everything automatically.
 

techElder

Well-known member
Hippy, why am I sensing that this is the beginning of something you've been working on for a bit of time? As for me, I've not heard of this angle from RevEd, but it sounds interesting. +1
 

hippy

Senior Member
Hippy, why am I sensing that this is the beginning of something you've been working on for a bit of time?
No, only since yesterday. I saw it as one of those "It's got to be easy to do this" challenges, and I had nothing better to do on a wet and windy afternoon than try it.

I have never really had much interest in IoT though I can appreciate wanting to record environmental data in the cloud, activate other things remotely, respond to incoming actions, use the network to link PICAXE together, have the PICAXE present a web page and respond to link clicks.

It always seemed to me that's not happening at any scale because there aren't any simple How To guides. It's the old "you have to know what you are doing before you can do it". So I do appreciate people complaining that it's hard, could be better.

The hard part is how one would do it. It's easy to say "Integrated PICAXE Solution" but rather harder to define what that would be, what it would have to support, how it would do it.

The only way I can see of doing it is to actually do it and document it, discover what people actually mean by "Control my PICAXE from a phone" and provide the means and mechanism to do that. Somewhere between 'nothing' and 'one chip solution' is a PC and/or Pi solution connected to a PICAXE which does what needs to be done. Once done and documented that can be used with ease which is where I am heading at present, though no promises as to where I will get to.

Porting that to an ESP or integrating it all on a PICAXE chip is something for the future. The problem I perceive is not how it's done but how to use it. I don't see a few extra steps, needing particular hardware, having two chips on a board rather than one, or using a Pi instead of an ESP is much of a problem if it's still easy to do. It is in my mind much better than nothing, and easier than the alternatives. To me it's more about documenting the How To than anything else. As long as it works it doesn't really matter how it's achieved. It might not be the perfect solution but it is a solution, and one which is in our grasp.
 

Buzby

Senior Member
... This is where the main difficulty lies; nailing down exactly what IoT means, what Wireless Connectivity means.
Once a board has a microprocessor and a WiFi UART, it's functionality is limited only by the firmware in the micro. ( I was impressed by the ability of the ESP BASIC to build an interactive webpage just by using BASIC instructions. )

The firmware could be a full-blown web-server, or just a light-weight MQTT client. With modern chips it should be possible to have a few different 'personalities' in the firmware, selectable by the user's PICAXE. A PE6 wizard would allow updating the PIC firmware as new 'personalites' are added.

Hippy, why am I sensing that this is the beginning of something you've been working on for a bit of time?
Because Rev-Ed have probably done 90% of the development work already !.

The PNS had a PIC running firmware to a low level Ethernet interface. A new board would use a similar setup, but to a low level WiFi interface.

The PNS firmware contains most of what is needed to send and receive packets via a WiFi device, as it's hardly any different to an Ethernet device. It also has code to 'translate' pin states and variable values into HTML for the web-server, which is not much different to sending them out directly.

I really do think a properly designed, single-source, one-board solution would be a winner, and Rev-Ed have a head start with the PNS and their familiarity with Microchip products.

Anyway, I've exhausted my say on this. Still got 'dumb' projects to finish.

Cheers,

Buzby
 

hippy

Senior Member
Rev-Ed have probably done 90% of the development work already !.

The PNS firmware contains most of what is needed to send and receive packets via a WiFi device, as it's hardly any different to an Ethernet device.

Rev-Ed have a head start with the PNS and their familiarity with Microchip products.
I don't know of any projects going on here related to IoT or WiFi other than what I did yesterday.

The PNS was a Microchip reference design (PICDEM.Net) which was minimally adjusted to interact with a PICAXE. I doubt the TCP/IP stack side of things was even looked at.

While the TCP/IP stack will be common for ethernet and WiFi ( and anything else ), WiFi has layers on top which can make it particularly awkward to use, not least the security aspects which require full cryptographic functionality. It's usually that which holds up implementation if the WiFi module itself doesn't have that embedded within it. One of course wouldn't likely choose one which didn't as a product developer.

The main reason what I've done has come along so quickly is that I can use all the libraries provided which allow me to issue a simple 'reply = WGet(url)' to send a command and see what the reply is. All the hard work behind that has been done for me by people who know what they're doing.

As long as it's connected to the network, ethernet, WiFi, Bluetooth, SLIP, USB, 4G/5G it just works. In fact that's an argument for using something which does all that straight out of the box rather than a module which maybe supports only 2.4GHz WiFi and IPv4.

Using a Pi as if an ESP or WiFi-UART has additional advantages. My remote Pi is speaking "Button pushed" and "Button released" when I push the button connected to my PICAXE -
Code:
#Include "iot.inc"
Target("192.168.0.130")
Do
  Do : Loop Until pinC.3 = 1
  Say("Button pushed")
  Do : Loop Until pinC.3 = 0
  Say("Button released")
Loop
I guess it could also be used as a ThingSpeak-like server, showing graphs locally, even acting as a 50" HDMI, large LCD text terminal. The best thing is it's near infinitely extensible, ridiculously easy to upgrade for new capabilities or services.

And it doesn't require a new PICAXE, even works with an 08M2 if only sending to a remote server. Put a Pi in a box, power in one end, serial to jack connector on the other, label it "PICAXE IoT Bridge", plug it into a PICAXE download socket and the job's done. One could even connect the PICAXE direct to the Pi's GPIO header, no serial cable needed, and put it all in the same box. That's why this approach appeals to me.
 

lbenson

Senior Member
I was quite excited by the idea of using the Pi (Z-W) for this process, but I've had too many instances of corruption of the SD card for unknown reasons to think that the future lies there. And the Pi is not so good for battery operations--around 6 hours on a single 18650 in my experience (of course continual Wifi connection will always represent a current drain).

I also have a Pi Z-W which has survived a number of hard power cycles without SD failure, and there apparently are things you can do to harden the SD. What I have liked about the little openwrt linux devices is that everything is in flash, and they survive abrupt power losses with nary a hitch--but for the most part they're hard to use for sensor readings and the like, especially when compared to PICAXE.
 

kfjl

Member
Hi everyone,

I've never seen anything like this before:

#Include "iot.inc"
Target("192.168.0.130")
#Define HasWebPage

I did a forum search for #Include "iot.inc" and got a "No results found" answer.

I searched for #Define HasWebPage and that brought me back here.

Is that code from a manual one got with the obsolete PNS?
 

lbenson

Senior Member
The targets you can search for are "#include" and "#Define"--"iot.inc" and "HasWebPage" will be unique to this thread (so far), as hippy is just now developing their usage. "#include" and "#Define" are Preprocessor Directives, shown on page 8 of manual 2 (in the copy I have).
 

hippy

Senior Member
For #INCLUDE ...

http://www.picaxe.com/BASIC-Commands/Directives/hash-include

Quite simply it allows code which would be in a program to be put in a separate file.

If you create a 'myfile.basinc' which contains -
Code:
#Define  Say(txt) SerTxd( txt, CR, LF )
You can create a 'program which contains -
Code:
#Include "myfile.basinc"
Do
  Say( "Welcome to include files" )
  Pause 1000
Loop
That works in Simulation and on a real chip.

The advantage of this approach is that, once you have an include file, you don't have to worry about what's in that, don't have to have its contents cluttering up your main program, can focus on what you want to do in the main program.
 

kfjl

Member
Thanks for the replies.
My question wasn't about what "#include" and "#define" mean, rather, "Where can I find iot.inc?".
I thought it was from a manual that came with the PNS module.
 

hippy

Senior Member
"Where can I find iot.inc?
You can't. That was library code I created in the last couple of days. Or rather couldn't, as I have now included it below. Note that this is incomplete.

Code:
IotLibrary28X2:

;       .--------------------------.
;       |                          |
; RX >--^-->| 6  SI    B.2 23 |    |
; TX <------| 7  SO    B.1 22 |    |
;           | 8  0V    B.0 21 |    |
;           | 9  XTL    +V 20 |    |
;           | 10 XTL    0V 19 |    |
;           | 11 C.0   C.7 18 |<---'  HSerIn
;           | 12 C.1   C.6 17 |       HSerOut
;           | 13 C.2   C.5 16 |
;           | 14 C.3   C.4 15 |
;           `-----------------'

Symbol IOT_HAS_ARG    = $80
Symbol IOT_REPLIES    = $40

Symbol IOT_REPLY      = $01
Symbol IOT_TARGET     = $02

Symbol IOT_LOW        = $10
Symbol IOT_HIGH       = $11
Symbol IOT_TOGGLE     = $12
Symbol IOT_PULSOUT    = $13 + IOT_HAS_ARG

Symbol IOT_READADC    = $20 + IOT_REPLIES
Symbol IOT_READADC10  = $21 + IOT_REPLIES
Symbol IOT_READTEMP   = $22 + IOT_REPLIES
Symbol IOT_READTEMP12 = $23 + IOT_REPLIES

Symbol IOT_SENDTS     = $30
Symbol IOT_WEBPAGE    = $31
Symbol IOT_ACTION     = $32 + IOT_HAS_ARG
Symbol IOT_ASK        = IOT_ACTION + IOT_REPLIES
Symbol IOT_SAY        = $33

#Define STX           "[-"
#Define ETX           "-]"

#Define Reply(val)          SerTxd(STX,IOT_REPLY,#val,ETX)
#Define Target(url)         SerTxd(STX,IOT_TARGET,url,ETX)
#Define SetHigh(pin)        SerTxd(STX,IOT_HIGH,pin,ETX)
#Define SetLow(pin)         SerTxd(STX,IOT_LOW,pin,ETX)
#Define SetToggle(pin)      SerTxd(STX,IOT_TOGGLE,pin,ETX)
#Define SetPulsOut(pin,val) SerTxd(STX,IOT_PULSOUT,pin,",",#val,ETX)
#Define SendTs(key,chn,val) SerTxd(STX,IOT_SENDTS,chn,key,",",#val,ETX)
#Define Action(cmd,val)     SerTxd(STX,IOT_ACTION,cmd,#val,ETX)
#Define Ask(cmd,val)        SerTxd(STX,IOT_ASK,cmd,#val,ETX)
#Define Say(txt)            SerTxd(STX,IOT_SAY,txt,ETX)

Symbol iotRxd = w25 ; b51:b50
Symbol iotVal = w26 ; b53:b52
Symbol iotCmd = b54
Symbol iotPin = b55

IotLibraryInit:
  Pause 1000
  Disconnect
  HSerSetup B9600_8,%00111
  Gosub Interrupt_Enable
  Goto EndOfIotLibrary

Interrupt:
  Do
    Do : Loop While ptr = hSerPtr : iotCmd = @ptrInc
    Do : Loop While ptr = hSerPtr : iotPin = @ptrInc
    If iotCmd >= IOT_HAS_ARG Then
      Do : Loop While ptr = hSerPtr : iotVal = @ptrInc * 256
      Do : Loop While ptr = hSerPtr : iotVal = iotVal + @ptrInc
    End If
    Select Case iotCmd
      Case IOT_REPLY      : iotRxd  =  iotVal
      Case IOT_HIGH       : High       iotPin
      Case IOT_LOW        : Low        iotPin
      Case IOT_TOGGLE     : Toggle     iotPin
      Case IOT_PULSOUT    : PulsOut    iotPin, iotVal
      Case IOT_READADC    : ReadAdc    iotPin, iotVal
      Case IOT_READADC10  : ReadAdc10  iotPin, iotVal
      Case IOT_READTEMP   : ReadTemp   iotPin, iotVal
      Case IOT_READTEMP12 : ReadTemp12 iotPin, iotVal
      Case IOT_WEBPAGE:
        #IfDef HasWebPage
          SerTxd(STX,IOT_WEBPAGE)
          Gosub WebPage
          SerTxd(ETX)
        #Else
          SerTxd(STX,IOT_WEBPAGE,"No Web Page",ETX)
        #EndIf
      Case IOT_ACTION, IOT_ASK
        #IfDef HasActions
          Gosub Actions
        #EndIf
    End Select
  Loop While ptr <> hSerPtr

Interrupt_Enable:
  hSerFlag = 0
  SetIntFlags %00100000, %00100000
  iotCmd = iotCmd & IOT_REPLIES
  If iotCmd <> 0 Then
    Reply(iotVal)
  End If
  Return

EndOfIotLibrary:
 

kfjl

Member
Thanks for posting that.
I got drowned in all those "#Defines" and "Symbols". I know they're supposed to make a program easier to read, but for me, they do the opposite.
I remember going through @srnet's LoRa programmes and replacing all the symbols and #defines by the numbers they represent in the LoRa datasheet so I could follow what he was doing.
I'll stick with ajax for my web stuff.
 

hippy

Senior Member
I got drowned in all those "#Defines" and "Symbols". I know they're supposed to make a program easier to read, but for me, they do the opposite.
But, the beauty of it all is that as a "user" you don't need to understand it, only have to use it. It's the not having to understand it which makes it easy to use, and I think that lack of abstraction has been the main problem with doing IoT in the past.

Having to deal with building AT commands and decoding what comes back is what makes it difficult for people. If that can be hidden then it becomes so much easier to use. Of course if one does want to understand what's going on under the hood one does need to get to grips with some quite complicated stuff but most people don't.

I have actually rediscovered I'd done more with ESP8266 and AT commands than I had thought; because they are the HC-01 and HC-05 amongst others, and I did do some work with them, even created the abstraction for those.

If you think the "iot.basinc" is tough going you should see the ESP8266 AT command stuff!

I did manage to get a PICAXE working as an Access Point scanner, as an Access Point for a phone, serving web pages and being controlled remotely, requesting information from other sites, but think I must have run out of steam because it never got completed.

Attached is what I had for a PICAXE-28X2 with ESP8266 connected to my WiFi router having a LED controlled by a web page and sending back an ADC value ...
 

Attachments

kfjl

Member
That looks a lot more friendly!

If you think the "iot.basinc" is tough going you should see the ESP8266 AT command stuff!
If you think the ESP8266 AT command stuff is tough going you should see the ajax stuff! :)

I've attached what I use.

I'm trying to do a video that shows the result of these two programs but it looks like my smart phone (hate the things!) is smarter than me.

DailyMotion doesn't seem to like me either.
 

Attachments

techElder

Well-known member
You can't. That was library code I created in the last couple of days. Or rather couldn't, as I have now included it below.
[/code]
The problem that I've had with "including libraries" is you run out of space in a PICAXE purty quickly.
 

Buzby

Senior Member
The problem that I've had with "including libraries" is you run out of space in a PICAXE purty quickly.
Yes, they are included files, not libraries. The clue is in the name. An 'include' file is included just as if it was 'cut & pasted' into your prog, whereas a library is a store where you take only that which you need, the rest stays where it is.

If you build an include file with ten subroutines in it, but your main program only uses one, the other nine are still compiled and take up space.

However, if the include file contains nothing but #macros, then only the used #macros get compiled. While this sounds like a solution, there is still the problem inherent in macros that each 'call' to a macro is actually an expansion, so your code gets bigger anyway.

What we need is a system that only compiles subroutines that are actually used. This would probably be a mod to the pre-processor, so no changes to the compiler or PE6 itself. This method would give PICAXE a true library facility.

Cheers,

Buzby
 

lbenson

Senior Member
Attached is what I had for a PICAXE-28X2 with ESP8266 connected to my WiFi router having a LED controlled by a web page and sending back an ADC value ...
This is brilliant code. I have it working on a 40X2. At first I had some trouble getting it to connect. I increased the timeout to 2 seconds. Still trouble, but after a few attempts it got there and served the page. Then it seemed to become more reliable at connecting. I wonder if the ESP8266 goes through some learning process to make new connections work better as time passes. (By the way, I'm using an ESP8266 D1 Mini module.)

Then I loaded my own HTML. It didn't show up, and when I clicked "view source", it was truncated. This baffled me for a while until I realized that I had to set AT+CIPSEND. That worked.
pushbuttons.jpg
When I clicked the right button, sertxd shows me "url=?A=1", so I know the code is extracting the item names and values. But I don't yet see where I need to put code to handle that input and act on it. Where do I look?

Here is my html. I seemed to need the PAUSE 50 after each HSEROUT, but that may have been an anomaly when other things were confusing me.
Code:
  HSerOut 0, ( "<html><head><title> Submit Button Test</title></head>" )
  pause 50
  HSerOut 0, ( "<body><form name = input method = get>" )
  pause 50
  HSerOut 0, ( "  <button type=submit value=0 name=B>Turn LED Off</button>" )
  pause 50
  HSerOut 0, ( "  <button type=submit value=1 name=A>Turn LED On</button>" )
  pause 50
  HSerOut 0, ( "</form></body></html>          " )
  pause 50
I put
length=228 ' LB 200303

before

Gosub SendReply_SendLength

In the HTML code, it appears that the quotation marks are not needed (at least with Chrome and Firefox)--perhaps unless there would be spaces within the quotes.

I note that I am getting phantom powering of the 40X2, perhaps on the HSERIN pin from the ESP. I need to experiment to see if an inline resistor will cure that.
 
Last edited:

Hemi345

Senior Member
Lance, I'd make the "name" attributes for your buttons the same since you're dealing with one LED, using just "A" or better yet, "L" for LED. The query string when clicking a button will be ?L=0 for off or ?L=1 for on. Then in the PICAXE code, you would look for L= and the 3rd byte would be what you'd use to control the LED.

Just a quick scan of Hippy's code, it looks like you would probably put the logic to detect the query string command inside "ShowPacket_WithIndent". It looks like it's looping through the scratchpad there and maybe you just need to look for "L" and "=" and then note the byte that follows.
 

hippy

Senior Member
The problem that I've had with "including libraries" is you run out of space in a PICAXE purty quickly.
That can be a problem if the include file includes things you don't need to use, or the macros do things which cannot be moved out into subroutines, and subroutines are included which are not used. The following will take up about 128 bytes no matter what's in the 'MainLoop' -
Code:
#Picaxe 20X2

; === Below would be in an include file ===

#Macro ReadSignedInto(wVar)
  wVar = -12345
#EndMacro

#Macro DebugSigned(txt,wVar)
  SerTxd( txt )
  w0 = wVar
  Gosub ShowSignedW0_Sub
  SerTxd( CR, LF )
#EndMacro

#Macro SendOutSigned(pin,wVar)
  SerTxd( "[SENT," )
  w0 = pin
  Gosub ShowPinInW0_sub
  SerTxd( "," )
  w0 = wVar
  Gosub ShowSignedW0_Sub
  SerTxd( "]" )
#EndMacro

Include_Start:
  Goto PowerOnReset

ShowPinInW0_Sub:
  SerTxd( "Pin=", #w0 )
  Return

ShowSignedW0_Sub:
  If w0 < $8000 Then
    SerTxd( "+" )
  Else
    SerTxd( "-" )
    w0 = -w0
  End If
  SerTxd( #w0 )
  Return

; === Above would be in an include file ===

PowerOnReset:
  SerTxd( "Started", CR, LF )

MainLoop:
  Do
    ReadSignedInto(w1)
    DebugSigned("w1=",w1)
    SendOutSigned(B.0,w1)
  Loop
But, with careful use of #DEFINE to specify what you will be using in your 'MainLoop', you can control what is included and what isn't and minimise usage -
Code:
#Picaxe 20X2

; #Define USE_ReadSignedInto
; #Define USE_DebugSigned
; #Define USE_SendOutSigned

; === Below would be in an include file ===

#IfDef USE_ReadSignedInto
  #Define ReadSignedInto(wVar)    ReadSignedInto_Mac(wVar)
#Else
  #Define ReadSignedInto(wVar)    #Error "No #Define USE_ReadSignedInto"
#EndIf

#IfDef USE_DebugSigned
  #Define DebugSigned(txt,wVar)   DebugSigned_Mac(txt,wVar)
#Else
  #Define DebugSigned(txt,wVar)   #Error "No #Define USE_DebugSigned"
#EndIf

#IfDef USE_SendOutSigned
  #Define SendOutSigned(pin,wVar) SendOutSigned_Mac(pin,wVar)
#Else
  #Define SendOutSigned(pin,wVar) #Error "No #Define USE_SendOutSigned"
#EndIf

#IfDef USE_DebugSigned
  #IfNDef   USE_ShowSignedW0_Sub
    #Define USE_ShowSignedW0_Sub
  #EndIf
#EndIf

#IfDef USE_SendOutSigned
  #IfNDef   USE_ShowPinInW0_Sub
    #Define USE_ShowPinInW0_Sub
  #EndIf
  #IfNDef   USE_ShowSignedW0_Sub
    #Define USE_ShowSignedW0_Sub
  #EndIf
#EndIf

#Macro ReadSignedInto_Mac(wVar)
  wVar = -12345
#EndMacro

#Macro DebugSigned_Mac(txt,wVar)
  SerTxd( txt )
  w0 = wVar
  Gosub ShowSignedW0_Sub
  SerTxd( CR, LF )
#EndMacro

#Macro SendOutSigned_Mac(pin,wVar)
  SerTxd( "[SENT," )
  w0 = pin
  Gosub ShowPinInW0_sub
  SerTxd( "," )
  w0 = wVar
  Gosub ShowSignedW0_Sub
  SerTxd( "]" )
#EndMacro

Include_Start:
  Goto PowerOnReset

#IfDef USE_ShowPinInW0_Sub
  ShowPinInW0_Sub:
    SerTxd( "Pin=", #w0 )
    Return
#EndIf

#IfDef USE_ShowSignedW0_Sub
  ShowSignedW0_Sub:
    If w0 < $8000 Then
      SerTxd( "+" )
    Else
      SerTxd( "-" )
      w0 = -w0
    End If
    SerTxd( #w0 )
    Return
#EndIf

; === Above would be in an include file ===

PowerOnReset:
  SerTxd( "Started", CR, LF )

MainLoop:
  Do
    ; ReadSignedInto(w1)
    ; DebugSigned("w1=",w1)
    ; SendOutSigned(B.0,w1)
  Loop
 

lbenson

Senior Member
I'd make the "name" attributes for your buttons the same since you're dealing with one LED, using just "A" or better yet, "L" for LED
Good idea. Thanks. Found where the "?L=0" stuff would be handled. Now have to figure out which variables have been used, which are available, and how to fold in my typical usage (e.g., of ?L=1&A=5&B=12345&C=0) into the scheme of:
Code:
 ' . . . code to get next name A-Z, e.g., "L", move ptr 2 bytes forward
    select htmlname
       case "L": action=@ptrinc: if action="1" then: HIGH pLED: else: LOW pLED: endif
       case "A": action=@ptrinc
          select action
            case "0": ' do this
            ' . . .
            case "9": ' do that
          endselect
       case "B": bptr=5_byte_location: do while @ptr <> "&" and @ptr <> 0: @bptrinc=@ptrinc: loop
          ' do something with 5_byte_location
       case "C":  action=@ptrinc: if action="1" then: HIGH pLED2: else: LOW pLED2: endif
    endselect
 
Last edited:

lbenson

Senior Member
hippy--I tried with a 20X2, and got "<OVERFLOW>" followed by a lot of garbage. Is there a convenient way to report but then ignore overflow, and try to find the end of packet and then the desired output in what is in the scratchpad?
Code:
Ready

Power-On Message...
  <130>rl<140><158><226><140>b<12>l<140>br|<12><142>bp`<236>l<236>b<18>lr<140>lb<236><242>n<238><128><18>nn<226><16><2><12><2><140>l<242>p<2><12>l<12><140><12>l<140><142><140><12><140><12><12><142><30><142>l<142><14>l<128><2>n<252><0><140><158><226><140>b<12>l<236><142><28>p<12><12><2><2><140><158><226><140>b<12>l<12><140>bprlrl<CR><LF>
  ready<CR><LF>

Reset module
PACKET FULL
<OVERFLOW>
  B+512KB)<2><12><2><140>l<242>p<2><12>l<130><140><142><140><12><140><12><12><142><30><142>l<142><14>l<128><2>n<252><0><140><158><226><140>b<12>`<2>rl<CR><LF>
  n|<236><12><140><12><142>|rl<140><226>r<146>l<140><12><12><12>l`<2><140><226>r<146>l<236>l<18><140><12><12><12>l`<2><140><226>r<146><140><12><12>ll`<2>rl<142><130>rl<140><158><226><140>b<12>l<140>br|

etc.
[/code[
 

lbenson

Senior Member
I got a bit further by changing the code after: HSerOut 0, ( "AT+RST", CR, LF )

to this, commenting out the ReceivePacket and ShowPacket lines, pausing for 2 seconds, and setting ptr and hserptr to 0:
' LB Gosub ReceivePacket
' LB Gosub ShowPacket_Indented
pause 2000 : ptr=0 : hserptr=0 ' LB

But then, after connecting, getting an IP address, and "waiting for request", after entering the ip address in my browser, I get "Unknown Request". I don't know if this is related to my setting ptr and hserptr to 0, or what.
Code:
Ready

Power-On Message...
  rl<140><158><226><140>b<12>l<140>br|<12><142>bp`<236>l<236>b<18>lr<140>lb<236><242>n<238><128><18>nn<226><16><2><12><2><140>l<242>p<2><12>l<12><140><12>l<140><142><140><12><140><12><12><142><30><142>l<142><14>l<128><2>n<252><0><140><158><226><140>b<12>l<236><142><28>p<12><12><2><2><140><158><226><140>b<12>l<12><140>bprlrl<CR><LF>
  ready<CR><LF>

Reset module

Version Details
  <CR><LF>
  OK<CR><LF>

Configure as station
  AT+CWMODE=1<CR><CR><LF>
  <CR><LF>
  OK<CR><LF>
  WIFI CONNECTED<CR><LF>

Connect to access point
Got so far...
  AT+CWJAP="MySSID","MyPW"<CR><CR><LF>
  WIFI DISCONNECT<CR><LF>
Got so far...
  AT+CWJAP="MySSID","MyPW"<CR><CR><LF>
  WIFI DISCONNECT<CR><LF>
  WIFI CONNECTED<CR><LF>
Complete packet
  AT+CWJAP="MySSID","MyPW"<CR><CR><LF>
  WIFI DISCONNECT<CR><LF>
  WIFI CONNECTED<CR><LF>
  WIFI GOT IP<CR><LF>
  <CR><LF>
  OK<CR><LF>

Connected

Connected status
  AT+CIPSTATUS<CR><CR><LF>
  STATUS:2<CR><LF>
  <CR><LF>
  OK<CR><LF>

Our IP Address
  AT+CIFSR<CR><CR><LF>
  +CIFSR:STAIP,"192.168.1.223"<CR><LF>
  +CIFSR:STAMAC,"5c:cf:7f:88:c8:7b"<CR><LF>
  <CR><LF>
  OK<CR><LF>

Allow multiple connections
  AT+CIPMUX=1<CR><CR><LF>
  <CR><LF>
  OK<CR><LF>

Start server on port 80
  AT+CIPSERVER=1,80<CR><CR><LF>
  <CR><LF>
  OK<CR><LF>

Waiting for requests...

Unknown request
late<CR><LF>
Accept-Language: en-US,en;q=0.9<CR><LF>
<CR><LF>

Unknown request
/*;q=0.8<CR><LF>
Accept-Encoding: gzip, deflate<CR><LF>
Accept-Language: en-US,en;q=0.9<CR><LF>
<CR><LF>

Unknown request
0,CLOSED<CR><LF>

Unknown request
Accept-Encoding: gzip, deflate<CR><LF>
Accept-Language: en-US,en;q=0.9<CR><LF>
<CR><LF>

Unknown request
0,CLOSED<CR><LF>
 
Last edited:

lbenson

Senior Member
Perhaps I need to provide all my code, since I folded in Hemi's idea of invoking javascript on separate web server (pi), and I moved putHTML and processHTML to the main .bas program so that, assuming everything else worked, they would be the only things that needed to be changed in the program for it to be tailored to new html.

b5a.js on the pi
Code:
document.body.innerHTML = "" +
'<html><head><title> LED Control</title></head>' +
'<body><form name = input method = get>' +
' <font color=blue><font size=5>Picaxe Web Server</font><br><br>' +
'  <font color=black>' +
'  <table border="1">' +
'  <tr><td><input type="radio" id="A" name="L" value="1">LED ON</td>' +
'  <td><input type="radio" id="B1" name="L" value="0">LED OFF</td></tr>' +
'  <tr><td><input type="radio" id="C" name="P" value="1">PWM ON </td>' +
'  <td><input type="radio" id="D" name="P" value="0">PWM OFF</td></tr>' +
'  <tr><td><input type="radio" id="E" name="R" value="1">Ramp/Fade ON  </td>' +
'  <td><input type="radio" id="F" name="R" value="0">Ramp/Fade ' +
'    OFF</td></tr></table>' +
'' +
'  <p>PWM Duty Cycle:</p>' +
'  <input type="text" id="G" name="N"><br><br>' +
'' +
'  <p>Select LED:</p>' +
'  <input type="radio" id="R" name="X" value="R">Red<br>' +
'  <input type="radio" id="Y" name="X" value="Y">Yellow<br>' +
'  <input type="radio" id="B" name="X" value="B">Blue<br>' +
'  <input type="radio" id="G" name="X" value="G">Green<br>' +
'  <input type="radio" id="W" name="X" value="W">White<br>' +
'  <input type="radio" id="O" name="X" value="O">Orange<br>' +
'' +
'  <br><button type=submit>Submit</button>' +
'</form></body></html>        '
var ledStatus = arrayCurVals[0];  // this will be "0"
var pwmStatus = arrayCurVals[1]; //this will be "1"
var pwmRamp = arrayCurVals[2]; //this will be "1"
var pwmDuty = arrayCurVals[3]; //this will be, e.g., "321"
var ledColor = arrayCurVals[4]; // this will be "W"

if (ledStatus == 1) { document.getElementById("A").setAttribute("checked", true); }
else { document.getElementById("B1").setAttribute("checked", true); }
if (pwmStatus == 1) { document.getElementById("C").setAttribute("checked", true); }
else { document.getElementById("D").setAttribute("checked", true); }
if (pwmRamp == 1) { document.getElementById("E").setAttribute("checked", true); }
else { document.getElementById("F").setAttribute("checked", true); }
document.getElementById("G").value=pwmDuty
document.getElementById(ledColor).setAttribute("checked", true);
s.css on the pi
Code:
body {
    background-color: #d0d0d0;
}

h1 {
    color: #fff;
    font-family: Arial, Helvetica, sans-serif;
}
Hope I haven't broken anything too badly.

Here's what the page should look like:
js5_html3.jpg
 

Attachments

hippy

Senior Member
Code:
Waiting for requests...

Unknown request
late<CR><LF>
Accept-Language: en-US,en;q=0.9<CR><LF>
<CR><LF>

Unknown request
/*;q=0.8<CR><LF>
Accept-Encoding: gzip, deflate<CR><LF>
Accept-Language: en-US,en;q=0.9<CR><LF>
<CR><LF>
It looks like it's losing the start of the request which should look something like ...
Code:
GET /something HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate
Accept-Language: en-us,en;q=0.5
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
That is 372 bytes. It seems likely the 20X2 receive buffer in Scratchpad which is only 128 bytes is being overwritten with subsequent data, losing the data one wants to see.

The best way to test using a 20X2 would be to open a telnet link to port 80, and explicitly enter just the GET command without extra header -
Code:
GET /something HTTP/1.1<RETURN>
<RETURN>
 

lbenson

Senior Member
It seems likely the 20X2 receive buffer in Scratchpad which is only 128 bytes is being overwritten with subsequent data, losing the data one wants to see.
Thanks for the clue. I'm looking, but is there a convenient way on the 20x2 to prevent HSERPTR from wrapping to 0?
 
Top