Project

General

Profile

Additional Gadgets, Decoders and Utils for HouseMon/Jeebus (Flow based versions)

Added by lightbulb about 3 years ago

All,

I have finally gotten round to publishing a few of the most basic Gadgets etc to GitHub.
I have called the repo “flow-ext” (Flow-Extended - for want of a better name). It contains Gadgets, Decoders and Utils for both Housemon and Jeebus. (some of which I’ll create pull requests for the core jcw repo’s)
I have quite a few more that I’ll try get published in a few days.

https://github.com/TheDistractor/flow-ext

If you have JNu’s or ATTiny84’s and even GPS’s and BT Modems - check out the small tweaked SerialPortEx.
Use like this:

      feeds: [
        { tag: "baud", data: 38400,  to: "sp.Param" }
        { tag: "databits", data: 8,  to: "sp.Param" }
        { tag: "stopbits", data: 1,  to: "sp.Param" }

It has some documentation - but I’ll add more updates over next 24hrs

—lightbulb (aka TheDistractor)


Replies (13)

RE: Additional Gadgets, Decoders and Utils for HouseMon/Jeebus (Flow based versions) - Added by lightbulb about 3 years ago

All,

New NodeMap and PutReadings (that currently ‘upgrade’ the core behaviour to add readings from multiple network ‘s).
Also a little upgrade/downgrade util in https://github.com/TheDistractor/convert-rf-readings that helps you switch.
I needed this myself as I have multiple basestations on both 433 and 868 Mhz frequencies.
I hope to get something like this pushed back into ’core’ until we can refactor the rf pipeline if jcw agrees. (I’m thinking dispatch is a little fragile and causes brittle dependencies)

Anyhow - until then , this update should help keep people with this problem moving. If you don’t have multiple frequency receivers you wont need these features right now.

RE: Additional Gadgets, Decoders and Utils for HouseMon/Jeebus (Flow based versions) - Added by lightbulb about 3 years ago

All,

Added an extended HTTPServer Gadget, see: https://github.com/TheDistractor/flow-ext\#httpserver for info.
This Gadget and other changes that help support it have been submitted as a pull request to jcw/jeebus, until such time as they are incorporated you can use the alternative package in flow-ext. You’ll need to generate a server certificate (pem + key) and add them as parameters to the new gadget.
(I’ll do a quick wiki page over weekend incase you need instructions)
Instructions for using this alternative HTTPServer are in the README. If its gets incorporated into Jeebus, I’ll update flow-ext with appropriate message to use the original jeebus import again.
This change is key to being able to support OAUTH 2.0 in a secure manner, so we can access housemon from over the net with some feeling of comfort.
(for thats how I access my systems remotely)
I will be adding OAUTH 2.0 support shortly (unless someone does it first).

—lightbulb

RE: Additional Gadgets, Decoders and Utils for HouseMon/Jeebus (Flow based versions) - Added by tve about 3 years ago

I’m a bit confused by the band thing. I was expecting to use as a unique address for a node and leave the band to whatever gateways to the group. In other words, if there are N RF gateways of various types then somewhere I’d have a map of -> gateway in order to route outgoing packets. Yes, this does say that you can’t have the same group on multiple bands, but is that a real limitation? In the other direction, if you carried your proposal further you’d even add the RF technology, ’cause I could have an RF12B and an RF69W network both on 433Mhz and both using the same group. Then a node address would become . Heck, you could have two RF12B networks in the 433Mhz band at different frequencies using the same group.

In addition, the semantics of inter-node communication break. If node <212,1> sends a message to <212,2> that’s a local node-to-node RF path. If node <212,1> sends a message to <222,4> then the GW node of the first network could pick up the message and forward it to the GW of the 222 network for distribution to node 4 on its network. But if you allow reuse of groups across different bands it’s no longer clear whether <212,1> to <212,2> is a local message or needs to be forwarded.

Why not simply state that the group has to be unique across all networks?

RE: Additional Gadgets, Decoders and Utils for HouseMon/Jeebus (Flow based versions) - Added by lightbulb about 3 years ago

@tve,

This actually is not related to ‘communications’ (i/o) per-se. Its more about storage/display using default circuits examples.

Example:
You will note that in the ‘baseline’ setup.coffee that there is a NodeMap gadget that reads in setup data as so:

# the node mapping for nodes at JeeLabs, as pre-configured circuit
circuits.nodesJeeLabs =
  gadgets: [
    { name: "nm", type: "NodeMap" }
  ]
  feeds: [
    { data: "RFg5i2,roomNode,boekenkast JC",  to: "nm.Info" }
....

Now, this is specific to Jeelabs and used as an example - I myself have a different circuits..
You will also note that in the ‘default’ setup, rf12toDatabase uses this nodeMap data.
Finally, the readings are published from this data, which optionally is displayed on screen.

Now, lets say our fictitious (novice user) starts with 1 serial port RFDemo on 868Mhz - all is fine, your node g5i2 reports and displays as a roomNode fine. You web page displays data and your database gets its readings.

Now, plug in a second serialport for 433Mhz RF12Demo, add a ‘SerialPort’ circuit. And plug that circuit into the default
circuits.init:

circuits.init =
  gadgets: [
    { name: "replay", type: "replay" }
    { name: "SerialFor433", type: "SerialFor433" } #or whatever
...

Either way, unless you provide your own NodeMap implementation, your flow will go through the default NodeMap which is ignorant of ‘band/Freq’ and will therefore treat an input from (433Mhz) g5i2 as if is was coming from 868g5i2 (roomnode). If it really ‘was’ a roomNode, its output would replace the 868 data and you may not even realize it (flip flopping back/fwd) , if it was a RadioBlip is would fail in the decoder (roomNode != radioBlip).

If you dont mind upsetting your database, try it using my RadioBlipper Factory Gadget on the alternate (fake) frequency, and create a fake node using the same g?i? as something else you already use like a roomNode etc.

You could of course create completely separate circuits with dedicated rf12database implementations that were ‘each’ aware of this but imho this would be beyond the basic housemon user, this change simply allows the novice user to continue with 2 different bands using the same basic setup circuits, importantly, not corrupting their database should they use 2 frequency inputs.

Hope this helps, maybe I have misunderstood the original concepts, either way its a nice to have imo.

—lightbulb

RE: Additional Gadgets, Decoders and Utils for HouseMon/Jeebus (Flow based versions) - Added by tve about 3 years ago

Why support the same group number in multiple bands simultaneously? Group + node seems like a large enough address space, why do we have to add band to it? And as I pointed out, that’s not necessarily unique either since you can have multiple networks in the same band and using the same group using different radio technologies, or different center frequencies, or simply being physically separated. Gotta stop somewhere.

RE: Additional Gadgets, Decoders and Utils for HouseMon/Jeebus (Flow based versions) - Added by lightbulb about 3 years ago

@tve,

Here is a quick screenshot relating to above comments.
Note the last column.

JeeBus (1).png View (20.5 KB)

JeeBus (1).png View (20.5 KB)

JeeBus.png View (20.5 KB)

1995
1997
1998

RE: Additional Gadgets, Decoders and Utils for HouseMon/Jeebus (Flow based versions) - Added by jcw about 3 years ago

> Why support the same group number in multiple bands simultaneously?

I’m ok either way, since everything is presumably managed by the same person anyway.

RE: Additional Gadgets, Decoders and Utils for HouseMon/Jeebus (Flow based versions) - Added by lightbulb about 3 years ago

@tve,

I think we may be at cross purposes here.

I dont think it unreasonable to want to display data from an 868Mhz Group X, Node Y, and a 433Mhz Group X, Node Y on the same screen at the same time and keep the data in my database without corruption.

I do not think the current system allows this ‘yet’ without modification. The screenshot demonstrates the concept i am talking about.

Also I do NOT want to have to keep track of the fact I have used group 212 in 868Mhz and so therefore make sure I don’t use it in 433Mhz band.
I should be able to use 868Mhz 1-250 AND 433Mhz 1-250 AND 915Mhz 1-250 should I live in a country that allows this.

Quick Example: RFDemo defaults to Group 212 I think, regardless of band. You WILL get users that buy both and maybe not even change the default band…..Housemon should NOT place restrictions like that, users would never read the documentation to find out they could not?

I hope we are talking about the same thing? I maybe think you are also thinking about the ‘write’ issue, which is separate imho, but none the leess important - I have that resolved here already, using multiple endpoints, it works very well and is as easy as opting in a RFDemo or other device and using a write mask and then sending a message flow to into the circuit.

—lightbulb

RE: Additional Gadgets, Decoders and Utils for HouseMon/Jeebus (Flow based versions) - Added by lightbulb about 3 years ago

All,

One final point (and I’ll keep quiet).

I have a holiday home, that uses 868 on group 212 (was the default, I just kept it).
(Lets call this Remote Network A)
I also have two more Remote Networks I have an interest in. Both have 868 and 433, and both use combinations of 200, 212, 100 & 5 groups.
Lets call them B & C.

I currently have 2 different systems to monitor these 3 locations….my aim is to combine these onto ONE monitoring system. Either way I do not want to have to go alternate the groups so I can monitor them centrally. Additionally I have another use for HouseMon/Jeebus that needs same issue resolving.

Solution: Include a ‘Site’ identifier that defaults for the single use case, but can be leveraged for multiple remote networks.

I have not pushed this change yet, as still fleshing it out (and requires numerous server + UI changes). But - I plan to if/when jcw clears my current pull requests so I can sync that repo back up.

I hope you can appreciate the problems from those with ‘existing’ rf networks with nodes in hard to modify places ;)

RE: Additional Gadgets, Decoders and Utils for HouseMon/Jeebus (Flow based versions) - Added by tve about 3 years ago

Ok, since you really care about it and one solution isn’t any more correct than the other I’m fine going with a triplet as node address. We just need to be consistent and carry that through everywhere we have a “physical” node address, otherwise our various gadgets won’t work together properly.

RE: Additional Gadgets, Decoders and Utils for HouseMon/Jeebus (Flow based versions) - Added by lightbulb about 3 years ago

All,

For those interested I have updated a few Gadgets and added a few new ones to my Housemon/Jeebus/Flow repo.

Noteables are:

  • SerialPortEx Gadget now has ‘init’ options with supported delays within the init sequence (I needed this for a pump initialization sequence myself).
  • RangeMap Gadget allows you to do basic inline value mapping of flow.Message/flow.Tag data (value types!)

see: https://github.com/TheDistractor/flow-ext\#rangemap (its basic and very generic but works for me).

For those interested, I have had a successful RF12 Write network functioning for about 10 days now.
I will attempt to refactor this into a more generic solution over next 48hrs before adding to this repository. (I will need to strip out the additional categorization that I use myself).
If you had used the old RF12Registry/RF12Writer system within HouseMon 0.7, there will be a compatability layer so it functions almost the same from a ‘client’ perspective.

In short, I plan on switching my live HM0.7 to the new GO based HM0.9.1 this weekend - all being well !.
(Data (REDIS migration) and GUI mods will come sometime after.)

I’m not saying HM0.9.1 is by any means ready for prime time, but it can capture and process data as well as HM0.7 imho.

I’ll try and write up a few notes of my migration.

—lightbulb

RE: Additional Gadgets, Decoders and Utils for HouseMon/Jeebus (Flow based versions) - Added by tve about 3 years ago

Cool and thanks for sharing! How do you visualize or display any of the data?

RE: Additional Gadgets, Decoders and Utils for HouseMon/Jeebus (Flow based versions) - Added by lightbulb about 3 years ago

@tve,

Back in HM 0.7 I used a few different methods.
Graphs:
* I extended the default Graph page to store configs in database and therefore present based upon URL stem - gave me lots of graph page endpoints.
* I exported to RRD via cron for other uses
* and also have a REDIS to Google App Engine bridge that put data into my Google Apps spreadsheets etc.

GUI.
My Housemon 0.7 was actually mainly JQueryUI (with Zurb replaced with Bootstrap) with very little AngularJS, and where i needed integration I created some directive ‘stubs’.

Today in 0.9.1 I have moved more to AngularJS directives/modules etc. Still some JQuery left over tho…hopefully fully replaced next week.

For graphs I still use RRD, and Google Apps, with a gadget to do in 0.9.1 what my redis lua & coffee drivers did in 0.7.
I have ‘started’ to replace the 0.7 inbuilt graphs with equivalent SVG graphs, partly D3.js.
My JQueryUI components are now Angular directives but using SVG where possible. JqueryUI almost gone

I use my own websocket ‘clients’ in addition to websocket-jeebus - I’ll be publishing those soon also.

Finally - I have been using Cordova in conjunction with my websocket clients to create some ‘applets’ for my mobile (experimental).
(Think of this as Housemon ‘partitions’ tailored for a very specific set of operations usable on a mobile)

—lightbulb

    (1-13/13)