In case you are not on the new product RSS feed, we have three new modules.
Single relay module https://www.ghielectronics.com/catalog/product/464
Breadboard module https://www.ghielectronics.com/catalog/product/454
One wire module https://www.ghielectronics.com/catalog/product/452
@ Gus - Good to see these. I put together a relay driver much like this and had to put a pull down resistor on it to keep it from actuating during a reset. I am using pin 3 does pin 5 work different?
Some very nice additions! I only wish they’d been available when I placed my order last week 
What’s up with “X1”?
@ Gus -
“Warning: Observe extreme caution when wiring circuits to the power grid. Hire an electrician if you are not 110% sure of what you are doing.”
Wouldn’t 110% indicate overconfidence? 
Seriously, though…can never be too careful with A/C power.
And when can one expect them to be available via distributors? (Mouser)
@ njbuch - soon but you can contact them to get them sooner please.
@ Gus - what about the reset?
same
@ Gus - You didn’t answer my question about “X1”. What does it mean?
@ ianlee74 - Ahaha Ian it means just X1 ( times 1 ) … 
With 2 realys will be X2 I suppose …
I don’t think it’s that simple. All three of the new modules carry the “X1” tag. Me thinks Gus has another surprise coming 
X1-X16 … Maybe number of input/outputs?
Anyway, I am getting interested in the 1-wire module, are thinking that it might get interesting for my sensor-bonanza.
But, I cannot find any good examples of 1-wire sensors, except for a good deal of temperature sensors.
Btw, there is whole bunch of different 1-wire sensors, and I am sure that some more specs on the drivers capabilities would be beneficial.
Take care.
onewire devices are often “unique”. As you found, DS18B20 series temperature devices are the most common, then there’s lots of sensors that I’d call more “niche”… The framework has a decent amount of OW support, but most devices will need a specific set of custom code to handle it’s responses. I don’t know exactly what the driver here will do except wrap the framework calls - it probably won’t implement the specifics for individual device types.
Thanks
@ Gus - Could I then please request a specific set of devices that this module is built for, and which ones the existing driver might support…?
We already talk about this on the product page i think, the water proof temperature sensor. But you can use anything else with simple changes to the software.
The module is built for any one-wire device. That means you can connect any one-wire device to the module and it will work. I’d suggest if you haven’t already done so, take a look at how OW devices are used within netmf, that will tell you how you generally use the devices, and then you can look at the specifics of how you would read and write values from each device - it’s unlikely, in my view, that there’d be much more abstraction that the Gadgeteer driver would offer since this really is just a generic OW “connector” / “adapter” rather than something targeted at a specific use case, but GHI would be best situated to tell us if their plans went above that.
(here’s my crystal ball - the driver will just wrap the OW device specifics that you need so you don’t need to define sockets and pins yourself, and that’s about it)
Random, off-topic thought I noticed when looking at the new modules: if you’re using large ceramics for power filtering, you don’t need 100n decoupling caps, as your larger ones will do the same job. Obviously not a huge savings, but I notice GHI puts a 4u7 + 100n ceramic combo on almost everything. Eliminating the 100n would reduce the number of BOM lines on a few of the modules.