RF Modules - RX480E-4 & TX118SA-4

RF - Radio Frequency

I recently got a RF transmitter/receiver pair from aliexpress.

I did the following video assuming that the receiver was bad!!! Apologies for the bad quality and pace.

However, it turned out to work fine!!! Just not the way I thought it would - the pin mappings were reversed in this case. There also was not much relevant documentation on the seller's page.

So below I will detail some important points about this RF transmitter/receiver pair

General Info

1. It has a encoder/decoder chips built-in. They are necessary for the process of communication. (They use some other chip - not HT12 kind).

2. They network in a different manner. You can pair "remotes" to a receiver and create a network or a channel - i.e a group of transmitters and a receiver that can communicate.

3. Typical applications include toggling a relay that controls your living room light, etc...

I am seriously considering this for two other applications:

1. Remote bike alarm - so I can find my bike in an open bike parking space.
2. Game show buzzer with a team board. When a team presses the buzzer their corresponding team's light indicator should blink.

Modes of operation

It has three modes of operation:

1. Momentary
2. Toggle
3. Latched/Interlocked

Memory Wipe

You can press the learning button 8 times. The LED will flash 7 times to indicate it has reset i.e, forgotten all its previous configuration - all transmitters and its previous mode of operation. This operation is necessary if you want to change modes. However, after doing this, you have to re-pair all your transmitters.

Learning Mode

After a memory wipe you have to first set the receiver into learning mode and then program it to one of the above mentioned modes.

To set it in a momentary mode: Press the learning button once. Wait for the LED to turn on. (This indicates its in a learning mode). On the transmitter, push any button. Or more accurately, ground a pin. Wait for the above LED to flash 3 times. (This indicates it has accepted the setting and it has come out of the learning mode). Now it is ready for normal operation.

To set it in toggle mode: Hit the learning mode button 2 times. Rest of the process remains same as above.

To set it in latched mode: Hit the learning mode button 3 times. Rest of the process remains same as above.

Configuring more transmitters

Otherwise also called "pairing". The process is exactly similar to "learning". You "toggle" the receiver into the (corresponding) learning mode. Press any button on the new transmitter. Wait for it to exit the learning mode. And you are done.

Prototype setup for testing the momentary mode of usage. 

Stuff you need

1. jumper wires
2. breadboard
3. 5V/3.3V  DC power supply module (comes with a 12V adapter)
4. 5 x LED
5. 5 x 330 Ohm Resistor
6. 4 x Momentary push button

Wiring

Note: no need to connect antennae now. Its only important for range test or applications that require a long distance.

Momentary mode operation

1. Wipe Memory first.
2. Undergo "learning" for the momentary operation mode.
3. Test different buttons on the transmitter, and, see the corresponding LEDs on the receiver end light up.

Its that simple.

The alternate learning button

You can have the VT pin on the receiver pulled high through a 1k Ohm resistor momentarily to simulate a learning mode button press. Consider this alternative when you find pressing the small button on the board cumbersome.

Have a nice day.

Extras

Video showing different modes: https://www.youtube.com/watch?v=4uW7vx6JnxI

Seller listing page: https://www.aliexpress.com/item/4000064795450.html

Post an image of your breadboard if you like... ;)

Yes. I also performed a range test at my work place - Infosys Bangalore Main Campus. Got a range of about 290 m. (Line of sight).

An overview of Join

This is like a messaging app, by the same developer of Tasker. If you want to know more about Tasker click here. PushBullet comes close to what Join does.

Here are some of the things you can do between two join devices:

1. Paste clipboard from one device to another
2. Send text notes from one to the other
3. You can send a URL from one device to the other. If the latter device happens to be a phone/browser, it will open a new tab with the URL
4. Send voice messages. You can write text on one device. It will be played over at the other end.
5. Send files...

It is possible to run custom actions. Join actions are different from Tasker. They are limited to messaging. A good example is doing a broadcast message to all devices.

However, Join also registers as a Tasker plugin. Which means you can do all of the above from Tasker.

For e.g. I use a combination of Tasker & Join to control my music playing experience.

You can also make other devices talk to join devices. Almost all common APIs are exposed over HTTP. So for something running in a raspberry pi device, all it needs is to make a http request (cURL) to the http api to get a message across.

An overview of Tasker

These are two cool android apps. But they are paid apps. However, I think buying them would prove worthy - you won't regret it. They help in a lot of home automation use cases.

What is Tasker?

This android app helps us to automate many aspects of the android phone. For e.g.

1. Automatically turn down brightness from 9pm to 7am, and, put the phone in silent mode, and, also turn on dark mode on the phone.
2. You can program your phone to show you a popup message with the content from an SMS received from your loved one...
3. You can make tasker search your sms and report your latest bank balance!

How does tasker do this?

Sparing all the intricate details, there are three high-level concepts at work...

1. Actions
2. Tasks
3. Profiles

Tasker Actions

They are what they are - actions. An action is something tasker can do. It can be broadly classified into three categories:

1. Actions that change some system setting or state. For e.g. set volume level, reject call, running an app, writing to a file, setting the alarm, clearing notifications, etc...
2. Actions that can help in networking. For e.g. make http requests, or, mqtt, etc.
3. Actions meant for notifications or interactions - toast messages, creating notifications, vibrating the phone, popups, etc.

So actions in a way are basic - they do one thing.

Tasker Tasks

A task combines multiple actions.

Tasker allows you to run tasks standalone or via means of a profile which is explained in the next section.

When running standalone tasker allows you to make shortcuts (or widgets) that you can place in your home screen. This is powerful - imagine having a task that can for instance talk to your home automation system and toggle your living room light switch...now you are controlling your living room light with your phone!!!

Tasker Profiles

A profile is a context for a task to run. A profile could be a combination of an event (like SMS message received), phone gesture, time, battery level, etc...For e.g. if you wanted your phone to turn on darkmode everday after 9pm you'd use a profile with one such "time" constraint. The associated task is the one that does the corresponding action. So as far as this small example goes, the profile is what triggered the specific task.

Tasker Plugins

Tasker has a finite set of actions and profile events. They can be extended with something called Tasker Plugins. For e.g. mqtt is something tasker doesn't provide out-of-the-box. However, there are tasker plugins which enable that feature for you. Now if you needed to send a mqtt message to some other device, you can find that specific action...Similarly tasker can respond to mqtt messages as well. There are plugins that enable this specific feature alone.

AutoApps

This is another app by the same developer. There are a number of tasker (3-rd party) plugins available today. This is a one-stop interface to get all those official tasker plugins.

Conclusion

I do recommend you explore this app. You will get hooked on to it very quickly.

Are you home power supply conscious?

Ever wondered if there is electricity at your house while you are at work? We used to live in an area of frequent power cuts. Sometimes they would take hours to come back on. And sometimes, it was simply human error: the meter reader would simply remove the fuse for the wrong apartment. In either case, my poor mother, would wait, hours on end, for it to come back on...

Hence I built a small android app using Google spreadsheet, and, Google Scripts.

That solution involved posting a "heartbeat" at a regular interval from the app. They were logged in a spreadsheet. The app at some regular interval, would get the records and there was some code written to find out if the last recorded heartbeat was quite long ago (say 15 minutes). If so, notify...

The highlight of that solution though was about recycling your old android phone which could be lying around with no real purpose other than accumulate dust.

Controlling your breadboard LEDs through Alexa

I am so into IoT these days. But the rate of experiments I do are small. Mainly because of travel, being stuck with something, failed experiments, blah blah blah...

But so far the journey is enjoyable. Today I thought why not show-off a bit. So here is a small wifi chip (wemos d1 mini) which is flashed with something called tasmota. (An amazing software). There are two LEDs connected to a resistor (330 ohm) (in series).

In the interest of DIY and brevity I won't detail how I did this through long and many-step instructions. But here is a gist of what I did. You may follow the images and video shared at the end of post.

1. Downloaded the latest release of Tasmota binary called sonoff.bin from the github repo
2. Flashed it onto the d1 mini using software called esptool.py (Other alternatives available).
3. Configured tasmota to connect to my home wifi router
4. Selected the appropriate device tasmota has to emulate. (Generic module).
5. Configured two GPIO pins as "relays" (on tasmota)
6. Configured friendly names and,
6.1 Enabled hue emulation (important) on tasmota
7. Ask Alexa to "discover devices"
8. Had fun...

Checkout the video and images too. (end of post).

So whats cool here?

Most people are not seasoned enough to understand this much less appreciate it. This is why I encourage DIY. So I am going to just "dive in"...you should too...

1. I didn't have to use a raspberry pi...(on an earlier exercise - I did use one such device).
2. No coding or IDEs required. (Get started with a simple Arduino project. You'll know what I mean...).
3. Except for voice recognition (viz Alexa's job) everything is intra-network. (Try something on Google Home to see what I mean - I don't have a Google Home device yet ;) ). (It only matters if you are worried about data privacy).

Conclusions

I have demonstrated the principle of switch automation - automation of your house appliances or light switches...

"Alexa, turn on bed room light" or "Alexa, TURN OFF THE DAMN TV"...the possibilities are endless.

It may not be your cup of tea. But that still doesn't physically limit you from trying...

So...Learn...Ask about stuff...Get frustrated trying...Get things done...Have fun.

PS: Perhaps Google Home might evolve into something better...I am waiting for that day... :)

About reading a formal specification document

Recently working with the DMN specifications for FEEL, I have come to better understand how a team should better approach the "reading exercise". So here are a few thoughts on how to read and what to expect, and what you may need.

1. Sans solo

You'll definitely go mad reading it alone. But the main point is, you can read it alone, but record your interpretations in the form of margin notes, or, example. So yes, its always better to keep a hard copy and read it. The notes can be small, but something concise that captures your thought at that point of time.

2. What is life, but a myriad of interpretations

When multiple people read the specs there is bound to be multiple interpretations. This is a good thing as long as its peaceful. But sharing those interpretations with your colleague or boss is a good thing. This way you can iterate through difficult sections of the specifications document, and resolve ambiguities.

3. There is always a community behind the specifications document

So its a good idea to use the internet and try to reach out to one such community. Because, sometimes, crowd-sourcing is good. Now you may not always hit the right idea, but, it opens up people to your interpretations. And sharing your interpretations is a good thing.

Chances are the community you are trying to be a part of might be really small. You may be under a deadline to understand a document, and, help doesn't come quickly. Expect the worst, but do share your thoughts, nonetheless.

4. Too many cooks are good here

Usually its always the developer reading the document. (Or developers). And his/her interpretations are "developer-ish". Perhaps its more focused towards implementation. Avoid this as much as you can. There should be a sales person, there should be a project manager, a very patient end stakeholder, etc involved in the reading exercise. They all will have their own interpretations. Some of them may be incorrect; some of them may be short-sighted. The mantra is share your ideas none the less, discuss, and, come up with the correct idea.

5. At least one right cook

Its always better to have a subject matter involved in the exercise. In most cases, one such person is absent. Then this advise is really not of much use to you. But if there is one such person, fish him out. It will only help.

So here are some thoughts I could write under 30 minutes. If you do have any you can share your two cents too.

Why I both hate and love the swagger-ui?

This post is a critique on swagger-ui and a specific react/redux pattern implemented over there.

Before you proceed, you may need to have some knowledge of the following:

• React/Redux
• Swagger UI
• Open API Specification, Loopback

OAS v3.0 (Open API Specification) is out. I was thinking of writing this post long ago when OAS was still 2.0. Now that team is probably migrating to support the latest specification. However, the scene at present is that most frameworks like loopback, still generate swagger.json as per OAS v2.0. Therefore the exercises I am about to show you might still convey the point.

The most negative aspect that sticks out is that the UI is simply too slow for large datasets.

Why? 

Because of the following line of code and what follows:

let taggedOps = specSelectors.taggedOperations()

Link

This is actually a very complex array-reduce operation. It is very well abstracted in this line, but bear with me. The initial load of the page (with the api info populated) is slowed down by the aforesaid operation. That is the slowness for the initial loading. But there is another aspect of its slowness.

React Reconciliation Process

The other cause for slowdown is react's reconciliation process which becomes apparent for large datasets. Any change in the redux state, triggers this reconciliation. React will do what its designed for - diff the current dom state with the virtual dom and only change those parts which have changed.

Sometimes the UI would freeze when you, say, toggle a tag. (A tag is synonymous to a model or a table in a database. All basic CRUD operations of that model will be grouped under that tag). With React, I believe the DOM manipulations are minimal - only the stuff that is changed changes. It is the diff computation that turns out to be expensive; and you cannot avoid it. Normally.

There are strategies to avoid it. One way to do so is that, we maintain the tag as a traditional react component which is disconnected from the redux store. Enough said. This is all theory. You probably want to manually verify this.
There are two ways about it.

1. If you have some service that generates the swagger.json (and webserver allows for CORS) you can plug that in directly to the petstore app and preview your apis. You will need a large swagger.json for this to convince yourself.
2. If you don't have a large dataset you can generate one using oeCloud. And then use the swagger.json generated there, in the petstore app for experimentation. 

I am going to follow the 2nd approach.

oeCloud is a loopback based framework which is geared to build enterprise grade applications. Its takes an API-first approach for fleshing everything out. On top of loopback, it supports personalization, eventual consistency, dynamic model creation or runtime model authoring, etc.

 Installing oe-cloud is simple: https://github.com/EdgeVerve/oe-cloud#install-this-node-module

(Make sure you have the prereqs)

 Post installation you might want to run the following two commands in succession in the project directory:
$ node . -m
$ node .


 The first command establishes some models required by the oecloud framework. The second command starts the server. You might see a message saying 'Browse your REST API at http://localhost:3000/explorer'

Note: make sure your port 3000 is available for this to work right away. You can configure this though.

Step 1 - Loading your API in petstore

What we want from oe-cloud is the following url:

http://localhost:3000/explorer/swagger.json 

Next we visit the petstore swagger app. Plug this url in the petstore app.

Step 2 - Observing the slowness 

Come down to ModelDefinition part - the first operation is a POST. Click it.

Notice that there was a slight freeze in UI responsiveness between that click and the subsequent UI state.

Alternatively we can do this in the developer console. (Just redo step 1, and continue with the following line).

In the developer console type:

ui.layoutActions.show(['operations','ModelDefinition', 'ModelDefinition_create'], true) 

...and hit Enter. This will do the same effect as above. We can see the delay either way. You may probably want to dig deeper at this point. But a fair warning, the code base isn't friendly for those who are not initiated to react/redux.

But what does swagger-ui do right? 

Yes, the slowness is a bum. But I had the opportunity to work with that code base and learn a few patterns for structuring a react/redux project. It is mainly their plugin architecture.

1. Swagger-UX relies on plugins for all the good stuff.
   
   This enables you to extend the swagger-ui application, write your own components, and make each component aware of the system. The "system" in this context is analogus to a mechanic's toolbox. As you write your own plugins you probably write your own components, some utility functions, etc. If you expose them they finally land in the toolbox. You can even re-use them in the react components you create and the pre-existing ones.
   
   The system has a factory method to load a component by its name. This is very useful for composing your react components.
   
   
2. Better design of your application state
   
   Each stateplugin your end up writing can either wraps something of an exiting state, extends it, or, creates a new state branch. Each state branch you create has its own actions, reducers, and selectors. When the application bootstraps you have neat namespaces via which you can access them.
   
   For e.g. recall what was done in the browser console above. 

For oeCloud framework, we had taken this code base and adapted to our needs. We have added code to handle our specific authentication needs. We also tweaked some performance issues that were part of the original swagger-ui project. You can reach that project here.

Warning: there are some minor bugs at this moment. If you happen to come across one please to raise an issue over there. Remember the original project was modified for oeCloud specific use. It may not be able to execute your APIs properly. But we can guide you nonetheless.

Links:

1. Petsore - http://petstore.swagger.io
2. Swagger Ui - https://github.com/swagger-api/swagger-ui
3. oeCloud framework - website, github - https://oecloud.io , https://github.com/EdgeVerve/oe-cloud
4. oe-swagger-ui - https://github.com/EdgeVerve/oe-swagger-ui