I tested this with the energy conduits from Enderio and the fluid pipes from Mekanism. After starting minecraft and a world loads the conduits will be disconnected most of the time (from turbine power taps) and the fluid pipes from turbine fluid port and reactor coolant port.

So far the problem does not seem to appear for me when interacting with mods other than big reactors.

http://i59.tinypic.com/2hi59n5.png <- picture after the world loads, a manual block update next to the pipe/port will fix it.

I am using 0.4.0rc2 for 1.7.10

This is a known issue (at least between Mekanism and BigReactors). The reactor blocks are sending out TileEntity updates (like a chest sends when it's inventory changes) when the reactor forms, but our transmitters (and apparently EnderIO conduits) are only receptive to full-on block updates. This has been fixed in Mek code in our most in-dev branch, it should hit the build servers before too long. It'll still exist between BR and EIO, though.

Thanks for the update.

Yep; this is a problem with EIO and Mek, as @unpairedbracket noted. Mek has a fix in, but you'll probably need to report this to EIO to get their conduits fixed.

I have no idea what this TileEntity event is or how to respond to it. Could it be pointed out in the mek/BR source to me?

Here is an example of a function scattering the TileEntity neighbor change event: https://github.com/CoFH/CoFHCore/blob/master/src/main/java/cofh/core/block/TileCoFHBase.java#L46

Here is a function signature for receiving it (note: on a block class):
https://github.com/CoFH/CoFHCore/blob/master/src/main/java/cofh/core/block/BlockCoFHBase.java#L169

It's Block.onNeighborChange(...) which is called by this function

so something like:

@Override
public void onNeighborChange(IBlockAccess world, int x, int y, int z, int tileX, int tileY, int tileZ) {
  TileEntity conduit = world.getTileEntity(x, y, z);
  if (conduit instanceof IConduitBundle) {
    ((IConduitBundle)conduit).onNeighborBlockChange(world.getBlock(x, y, z));
  }
}

(same code as in onNeighborBlockChange)

Yes, precisely. The advantage of onNeighborChange is that it includes the coordinates of the changed tile, so you don't have to perform six checks when only one is necessary.

ok, so is the onNeighborBlockChange method irrelevant, or still needed for compatibility with other blocks?

Up to you. I'm choosing to phase it out, which forces mods that want interoperability to switch over. You may prefer to not deal with the bug reports and just leave it in.

If it doesn't create duplicate updates, I will probably leave it in. Thanks for the help.