Main Site Documentation

IoT with FEZ rules them all


Hi All,

I have tried to use common .NET funcions like HTTP listeners and or several sockets functions but nothing seems to be implemented in TinyCLR. The program deployes without errors but generates the runtime exception: “Not implemented”. Are there any alternatives or am I doing something wrong? In the wifi.cs sample i have found HTTP send and requests but no listeners which are needed for IoT.

Thanks for all the help so far!

Best Regards,



Also functions in GHIElectronics.TinyCLR.Networking.dll are not implemenetd like wifi.GetPhysicalAddress(). Does this mean that the user had to fill in the gaps by updating Fez TinyCLR himself?

But may be I am the wrong path.

Hoping someone could help!

Best regards,

IoT with FEZ

Hi all,

There is very weak support for the Wifi module in the latest FEZCLR. Most .netmf functions are not implementated. The only way out is to send AT commands direct to the module. With such weak and buggy support I think such a general purpose function had to be added as one of first things. So is there a way to send AT commands to module? Or had this to be done with an interop?

I hope someone could shed some light on this!

Best Regards,


Sorry, just to be clear - FEZ is not a NETMF device. Don’t approach it from NETMF perspective, you need to be clear that you’re using TinyCLR OS…


Hi Brett,

Yes this is clear and much is missing. For our purpose it will be no problem however. I simple don’t use these nice functions in netmf which are not (yet) implemented in TinyCLR.

But for my goal can I use SPWF04SxCommand to send AT commands to the WiFi module? I now get a null reference exception with: new SPWF04SxCommand[1];. I thought may be the AT commands could be sent with AddParameter and Finalize(SPWF04SxCommandIds.AT)?

Thanks for your help!


and just to reiterate why I made my comment. If you’re looking for 1:1 mapping with netmf, don’t. The equivalent may be implemented elsewhere, and the NotImplemented error that you see thrown may just be to catch people who try to paste their old code into a TinyCLR project :slight_smile: You actually need to ask a different question: what networking functions should you be looking at to do task X, Y, Z (where only you know what you want to achieve)


Hi, I think that you can either wait until GHI has implemented more networking functions or you could write AT-commands to the WiFi module over the serial port. If you don’t have the time to wait and want to have access to more elaborated network functions as realized in the big .NET framework and want to use ready libraries e.g. to access Azure services it might at the moment be easier to use devices like the Beaglebone with Mono. Here is an example how it can be done:

However it has to be considered that the hardware is more expensive, setting up the system is more complicated and debugging is not as comfortable as on GHI devices.
Kind regards


Hi Brett,

I have no experience with other boards. This FEZ ‘Rules them all’ board is the first ever and so I have nothing to port. What I want to achive is that the FEZ board listen to commands like SOAP or REST web service. Clients had to be able to call web service functions like read value of sensor or writing a value to an actuator. The good news is that this can be achived with the current WiFi module. I only need to be able to send AT commands. But this can’t be done SPWF04SxCommand?

Thanks again for your support!


Hi RoSchmi,

Thanks again for your clear insights!

No I don’t want to wait. It will be great to use the AT commands. With the used ST WiFi module everything I want is possible. And you write that it is possible to write AT commands to the WiFi module over the serial port. So, I will try to find out how!

Kind Regards,


I must say that I never tried it. May be that the serial port can not be used besides the GHI driver. Perhaps GHI can give some hints.


Hi RoSchmi,

Can the TX/RX pins not be reached from an app like you reached other pins in your FEZWiFiUpdatePreset app? In that case commands could be sent as with TeraTerm. Perhaps a little bit ugly way however.



I didn’t yet look at this. However I had a look on the GHI Examples and it seems that socket client and socket server are implemented. I think that these classes can be used to achieve what you want.


Very nice work @RoSchmi! I think one should be able to pull off the same trick with dotnet core, as there are now ARM32 versions of dotnet core. That would make the debugging setup significantly simpler, as it’s already built into VS2017. I’m working on proving this out because it would give us full compiled execution speed for dotnet code on BBB (AM3358) and RPi (A53) chips, and a consistent API from TinyCLR right up through dotnet core. And both of those (BBB and RPi) are cheaper by $10-25 and should have faster execution than the meadow interpreter-based board (being jit’d rather than interpreted). IoT on Fez is completely doable and incredibly economical, but it’s good to have a consistent software path forward into higher speeds, and TinyCLR’s alignment with Microsoft APIs opens that door.


Hi RoSchmi,

That’s right and I have tried: var id = wifi.OpenSocket(sIP4, 80, SPWF04SxConnectionType.Tcp, SPWF04SxConnectionSecurityType.None) but problem is that all the implemented socket functions sees the FEZ as client not as a server. With the implemented function I can reach other web services or webservers. Where did you find the a socket server?



Thanks for the praise… which I have to give back, most of my instructions were from your knowledge base articles and Yes, would be nice to see this with dotnet.core


On a first look I had the impression that on this side are code samples needed to make a socket server

However I’m not very familiar with network programming. There are many skilled people around here who perhaps can have a look.


Hi RoSchmi,

Thanks again by reading WiFi.cs I found that wifi.OpenSocket could also listen to all network activity. This I will try first!


Sorry about this confusion. TinyCLR ships with many drivers. They are found here
While our goal is to add everything in the driver, we prioritize the TinyCLR code. Why? Users can always modify the drivers as they are managed code (C#) and the code is public.

And by the way, since ST has surprisingly discontinued their WiFi module, the drivers for it are even lower priority now. We want to revisit this in the future whenever time allows. And the community is of course welcome to to jump in and improve any of the existing drivers, including ST WiFi.


Hi Gus,

Thanks for the TinyCLR drivers link. I now see that your OpenSocket function uses the AT command SOCKON but I need SOCKDON. Next to OpenSocket i would like to have OpenServerSocket(int port, SPWF04SxConnectionType connectionType, SPWF04SxConnectionSecurityType connectionSecurity, string commonName = null) … which uses SOCKDON in stead of SOCKON in the Finalize function.

So close… I have donwloaded the project but it doesn’t compile…

Can you update please?

Best Regards,


Or a general purpose function that execute AT commands on the WiFi module.